I think most webfonts would work perfectly well for screen with a low UPM like 256.
I think most (if not all) of Font Bureau’s RE fonts are on 512 upem, using similar reasoning. I believe that this approach grew out of David Berlow’s experience creating the Prelude fonts for Palm. He figured in that case that even a single glyph enlarged to the full size of the device would hardly reach a pixel resolution that benefited from more unit resolution (or file size).
the best solution is to ask the client, and let them decide. For me, it
would be a nightmare if I had to change the font in any of the old
documents that I opened because the font's name had changed.
When working with clients on this sort of modification or customization, I always recommend a custom or modified name. And along with that, I offer to provide them with a script that will automate changes in legacy documents (assuming they are working in InDesign, which they almost always are).
Several years ago, when Font Bureau made a major update to the Benton Sans family, there was a lot of debate about the pros and cons of having the family name change slightly (from “BentonSans” to “Benton Sans”).
All of the familiar arguments arose — including preventing the possibility of documents that depend upon features in the new full-featured OT fonts from opening with older fonts installed and without warning of the mismatch (an argument for name change) versus causing confusion and hassle in updating existing documents (an argument for keeping the same family name).
The decision was made to update the family name.
As you can imagine, updating specimen documents that had contained around 128 fonts (prior to merger of SC styles) to roughly 80 fully-featured OT fonts was a daunting prospect. The Adobe Find Font… interface is very cumbersome at that scale. Which is when I developed my InDesign script.
I then suggested to sales & customer support staff to make the offer to clients that we could provide them the script to update legacy InDesign documents, as a courtesy. I don’t know if anyone ever took advantage of the offer.
Further to what @Khaled Hosny said about U+00AD being a control character, in the Unicode Standard, you will find this description in the chapter on punctuation:
Soft Hyphen. Despite its name, U+00AD soft hyphen is not a hyphen, but rather an invisible format character used to indicate optional intraword breaks. As described in Section 23.2, Layout Controls, its effect on the appearance of the text depends on the language and script used.
My preferred approach to U+00AD softhyphen is the same as U+00A0 nbspace — which is to say, I prefer to double-encode them with their default references hyphen and space.
These two are unique characters whose distinct properties I feel should be properly handled at a higher level than the font: the discretionary character of the softhyphen and the non-breaking character of the nbspace are characteristics that should be managed at the layout level. The glyphs themselves should be the exact same as the hyphen and space in every other way. I would guess that the fact that they are encoded at all is a legacy residue.
In practical reality, I believe most most modern apps treat them this way. If these codepoints are not present, then the renderer should use the U+002D hyphen and U+0020 space. In some apps, the renderer does so regardless. However, in some apps, the renderer uses the mapped glyph if the 00AD/00A0 codepoints are actually present. And if the glyphs differ from the 002D/0020 glyphs, then unexpected behavior can happen.
If you double-encode then you don’t need to be concerned with .case versions of U+00AD, since the hyphen glyph will be utilized and still be a proper target for any existing relevant GSUBs.
I wouldn’t even really bother with the codepoints in <cmap> except that I suspect there are a number of validators that would flag a font as not supporting various legacy codepages that include these codepoints (especially U+00AD) if these codepoints are not in fact present.
As such, I generally draw it as a nominal em dash — i.e., I make it a full em wide with zero sidebearings (which is not typically how I draw my emdash U+2014 these days).
In fact, I have a simple script that just creates the horizontalbar glyph with a width from f.info.unitsPerEm, reads the thickness and vertical position from the bounding box of my emdash, and draws the relevant rectangle. Never give it a second thought. ;-)