Good points, but I having a full scripting language would be overkill in my opinion.
Well, I meant it more like
"this is not difficult to implement; the problem is getting the application developers to agree on its behaviour, and actually USE these".
I could easily write a GTK+3
GtkEntry derivative in C or a Qt5
QLabel derivative in C++ or Python 3, that provide this functionality in a seamless drop-in fashion, under say CC0-1.0 (i.e., Do Whatever You Wish But Don't Blame Me license) or preferably the toolkit's own (least restrictive) license.
The hard work would be the human stuff, getting the application developers to use it, and not mangle it all to hell because they have odd notions on how their users should do this.
(As an example, the reason you cannot select UTF-8 as the default character set in your browser, is that someone decided that "UTF-8 is the only non-legacy character set". No, seriously, that's the rule, and all current browser developers go by that rule. What the hell does "legacy" even mean in this context? UTF-8 was first used in Plan-9 in 1992, ISO-8859-15 (which is not a "legacy character set") was first proposed in 1996, and adopted into the standard even later, so "legacy" definitely has no relation to time. It's just a word used to say "fuck you, we don't care, this is how we decided stuff so shut up already".)
Please note that I am describing this as a person who has provided patches to a LOT of different projects over the years, and know how the cycle goes. I have done something like this before, and am wary of trying to do it again, because it is so much social-interaction-work to convince people it is useful/necessary; at least an order of magnitude more than the programming work.
The one working approach I can see is getting the functionality integrated into the various GUI widget toolkits, GTK+ and Qt in particular. You do need to have personal contacts with people who have deciding power, however. I do not, any more. (Being a burnt out husk of a man, and so on.)
As to the technical details, I would implement these backed with three "dictionaries" or callback functions: one for variables, one for units, and one for functions. Variables would default to empty/not supported; functions would default to a basic set of trigonometric functions, square root, exponent, logarithm, and absolute value; and for units, there would be a few different default sets: one for lengths, one for angles, one for surface area, and one for volumes, at least. These would be easily extended or replaced by application programmers, but the default ones should cover most reasonable use cases, so they wouldn't, and this would Just Work in most applications.
If there is somebody willing to do the social work – convincing others to integrate this, pushing it upstream, etc. – I would be happy to do the development work. What I do not want to get involved in, is in the endless bike-shedding discussions into minute details on how this should be done before anyone has even tested it in real life.
Having thought about this some more, I think a version without unit support would be much more likely to be accepted by the developers. That would also remove one of the difficult questions – how to control the units used by the widget internally. (Unit conversions could be provided via functions, as described in my first post, though.)