Personally, for something like this I’m not sure that getting consensus really matters or is even desirable (death by design by committee is real). Just pick a direction and go. If it’s sufficiently good it’ll catch on and blossom from there, if it doesn’t go back to drawing board and try again.
The problem is that there aren’t even really any attempts out there. The closest as you say are web components, but they’re still extremely primitive relative to something like AppKit or win32.
> ...if it doesn’t go back to drawing board and try again.
My guess is that would put the burden of keeping up with evolving APIs on web developers and web companies. And there is a huge and very diverse ecosystem out there.
Native app developers seem to be burning resources trying to stay in stores and working on modern devices.
The new APIs wouldn’t be for everybody in the early stages and that’s fine. It’s impossible to build something that everybody can get on board with from day one. There will be early adopters who are willing to pay the price of admission.
Staying in app stores in my experience has not been particularly difficult or resource intensive. If you stick to first party toolkits and don’t go nuts with custom widgets, maintenance is minimal and often you only need to compile against a newer SDK every few years. The horror stories are generally coming from projects with severe NIH syndrome and sometimes of users of cross platform frameworks.
I mean, experimental APIs do get built this way, and some get adopted and some do not.
As it is, the vast majority of consumers want platform parity because nobody wants to feel left out of features on a second-class platform missing an API.
The problem is that there aren’t even really any attempts out there. The closest as you say are web components, but they’re still extremely primitive relative to something like AppKit or win32.