Just to clarify, it appears to me that your core question about a combined data and unit form field is beyond usage in a word processor because you state, "This is not limited to font size, of course, but applies to any numeric input field where the data has a unit. Even in “metric” applications, users may change the prefix, e.g. ‘cm’ to ‘mm’." And you emphasize this in a comment to an answer by stating that you believe that a "widget" can be created for the "combined data and unit form field." If I misunderstood, then you are welcome to disregard the rest of my answer.
I don't think creating a useful widget is possible. You have two base assumptions in the question: 1. in a large number of cases, numbers need units for meaning, and 2. units can use different measuring systems. Those commonalities are not enough.
The core issue lies with UI/UX in general: different users will have different backgrounds and expectations about any interaction you create. For example you should create a different interaction for experienced users compared to the inexperienced. An application with casual usage should have different requirements from one with heavy usage. Trained users will not need the same interaction as general public users. Platform standards should also be considered, since users will likely have expectations based on those experiences.
If your goal in asking this question is to find help with creating such a widget, then you will likely be dissatisfied with many answers. Even a satisfactory answer is likely to have faults and failures that are not necessarily obvious. To support all of the various options would require a complex widget, and then you need to consider the target for that widget - is it for you or internal to a company? In that case, you may spend excessive amounts of time trying to make the widget flexible for use-cases you don't use, or make your problem more complex than necessary by trying to create a "generic solution." For a developer tool in general, adoption will be your challenge.
If you are determined to try to create such a widget, here are some considerations that may help you do it (or persuade you not to do it) based on your questions:
- How do you best indicate to users that different units are supported?
For a font, you have several examples of implementations with a short list of units. I will not discuss the pros/cons because it depends on requirements, target users, available tools, etc.
Perhaps more important, in the general case a few unit options is very different than cases of 20 or more. Fonts have a handful of common units vs. distance where there are easily more than 20, depending on the use case. Specialized cases (for example form factors like mobile apps vs. desktop vs. tablet, etc.) require more consideration.
- How do you show which units are supported?
Again, for a short list of units it may be possible to display the data and all options simultaneously using a selector (i.e. radio button). Even so, space considerations may make that impractical. Other nearby elements may also make that confusing or helpful. Also, depending on professional vs. casual users there is the issue of being able to easily select from a very long list of units that are very familiar to the user vs. the need to make the unit options obvious.
- Should the value automatically change when the user selects a different unit?
This seems straightforward, but as you mention, it is not. A user may enter the value and then decide the unit is wrong and want to change it. While a designer may think automatic conversion improves usability, casual users are less likely to think about the units in advance of entering a numeric amount in many cases. A power user will simply memorize whatever it does. A professional may appreciate the automatic conversion and use it for other purposes. Similarly, a casual user may not notice the automatic change while a professional may notice. With this, you can see that an application targeted to the general public could in some cases benefit from automatic changes, and in other cases it would not.
It may be that usage statistics and/or testing result in a mixed bag of options even on the same screen, which could be the reason for what happened in the example you gave. A casual user might never notice what you noticed - and if they are not always accessing that area, creating a "common interaction model" is only a design goal, and may not actually help your users. A "power user" will adapt based on the need to do so, which may make the various interactions annoying, or maybe they don't care. It is really only annoying to people that notice and appreciate the higher level pattern, which is not the goal of UI/UX in general.
- What should happen if the user removes the unit altogether (if that’s possible) – previous or default unit?
This depends on whether the field has dependencies that might create problems. It also depends on if the interaction has meaning (a "clear" button vs. "select all" and "backspace" vs. repeated backspacing). You should determine how users and other fields are expected to interact with editable fields before deciding the appropriate handling of this case. In some situations, users may feel better seeing the number gone - and in others, it may make them uneasy. Re-populating has similar considerations. If users expect to be able to remove all data from a field and when they do it auto-populates, then it is not helpful.
- How would you deal with different kinds of units, i.e. absolute and relative ones, inside the same field? (Imagine CSS font sizes, which can be absolute, relative with percentage, absolute keyword, relative keyword or other keyword.)
From a UI/UX perspective, casual users will need more visual cues to understand that a "unit-less" number has an implied unit, or a "percentage" entry may need to display additional context or an example to be understood. For power users or trained users, this information may be unnecessary or even a distraction or hindrance (for cases where screen space is limited). Sometimes casual users do not know or understand the unit (or its symbol), so you may want to avoid using it for them at times also.
- Do you think typed cells would work well in spreadsheet applications?
Typed cells are fantastic for users like me that like to keep my hands on the keyboard as much as possible. Lists are more helpful for users that are less concerned with that, for cases options should be limited, for users that may need "prompting" or "example" data to help them determine the proper value and other similar situations.
I hope this is helpful. I can elaborate more if you like, but I think it's pretty lengthy already.
