I get why you want this, but I'm not sure how it actually work in practice without also sacrificing interoperability.
There are a number of reasons why we can basically expect everything to converge on all computers behaving exactly the same, even if the interop standard notionally says they don't have to:
* Any observable behavior will eventually be relied upon. You know, Hyrum's Law.
* Extending a protocol means that someone, somewhere is behaving differently in response to that protocol extension. This means extending a protocol changes its semantics, and that people will either rely on the extension being supported [1], or they will (accidentally or maliciously) create crap data in the extended namespace and penalize anyone who actually tries to use it [2].
* In other words, there is no such thing as optional features in standards. Either the feature works, and implementations that do not support it get fucked*, or it doesn't work, because the implementations that do not support it had enough clout to make it unusable.
* If vendor-locked-in solutions provide a better UX, a lot of people will just use that [3]. Especially if the locked-in version is a superset of the standard, and everyone gradually just moves to the version with proprietary extensions because fixing the interop hazards is more important than whatever feature ties them to a niche implementation. Consider how Linux EEE'ed POSIX. Was there a conspiracy, like with ActiveDirectory and LDAP? Or did it just sort of happen?
* By "get fucked", I mean "not interoperable." It might still be usable in a limited context, but that means network effects are working against it instead of for it. I need very, very good reason to use two different web browsers.
There are a number of reasons why we can basically expect everything to converge on all computers behaving exactly the same, even if the interop standard notionally says they don't have to:
* Any observable behavior will eventually be relied upon. You know, Hyrum's Law.
* Extending a protocol means that someone, somewhere is behaving differently in response to that protocol extension. This means extending a protocol changes its semantics, and that people will either rely on the extension being supported [1], or they will (accidentally or maliciously) create crap data in the extended namespace and penalize anyone who actually tries to use it [2].
* In other words, there is no such thing as optional features in standards. Either the feature works, and implementations that do not support it get fucked*, or it doesn't work, because the implementations that do not support it had enough clout to make it unusable.
* If vendor-locked-in solutions provide a better UX, a lot of people will just use that [3]. Especially if the locked-in version is a superset of the standard, and everyone gradually just moves to the version with proprietary extensions because fixing the interop hazards is more important than whatever feature ties them to a niche implementation. Consider how Linux EEE'ed POSIX. Was there a conspiracy, like with ActiveDirectory and LDAP? Or did it just sort of happen?
[1]: https://acko.net/blog/on-variance-and-extensibility/
[2]: https://web.archive.org/web/20070508200721/http://www.well.c...
[3]: https://signal.org/blog/the-ecosystem-is-moving/
* By "get fucked", I mean "not interoperable." It might still be usable in a limited context, but that means network effects are working against it instead of for it. I need very, very good reason to use two different web browsers.