POSIX + a standard library for UI components + containerization + webassembly would be the "correct", cleanroom solution in my opinion.
If you want to build and run "native but untrusted" applications on the user's computer on heterogenous environments and can't anticipate which APIs someone is going to need next. Well then give them access to a walled-off part of the computer.
Same-origin policy? Replace it with a l7 firewall (+ some DNS security manifests?)
No cookies/local storage? That just means spinning up a new container every time the user visits.
No audio playback? Don't map the sound device into the container.
Sounds like you're really poorly reinventing Inferno. I don't even understand why you would need WebAssembly in this hypothetical scheme.
Container namespacing isn't fine-grained enough, and much of this is the result of traditional Unix-likes having large disparities between different ways of naming things that cannot be composed. The Spring solution was to have all of these descend from a name service, and the Plan 9/Inferno solution to have all resources be multiplexed into virtual file systems (i.e. one way of naming things).
Furthermore, the inclusion of containers here gives you a worst-of-both-worlds approach. You're not even detaching resource subsystems from a unit of execution's POV, you're cloning the entire OS namespace modulo disallowed subsystems for every unit of execution. That's a combinatorial explosion of the state space.
It also means complicated solutions to the problem of resource management and communication within and between containers, which is a problem when virtualization occurs at a too high level. In contrast, virtualization at the process/task level with OS-wide capabilities for single-system imaging and a heavily integrated subsystem for naming things (either a one true approach or a prototype-based one) means you can configure a system like it's a whole unit without sacrificing security.
Then it's not like POSIX is even that great. Why should a process be associated with one uid? Why can't I dynamically attach and remove capability tokens from processes while they're running, like the Hurd does it?
I'm not too fixated on posix + containers. It's just what I'm familiar with.
It's more about what the complex web applications are trying to do: Run in an isolated context, run compiled code from whatever language the developer preferred and utilize various low level features in ways that people didn't predict in advance.
Basically, what's irritating is that the web standards committees are trying to hand-craft poor knockoffs of lower level APIs, one at a time in ways that are incompatible / don't interoperate well with existing native software. I mean you can't even pipe data in/out of a tab if you wanted to.
Instead it might be better to look at already existing APIs that have been refined over years + some security namespacing.
I'm sure you can do better than the POSIX APIs, but I think it's hard to argue that POSIX APIs are better than the Web APIs. POSIX is a terrible API with decades of cruft.
POSIX is actually pretty horrible, if you look at the details. Guess what the "close" function does (hint: you can't use it to close a window or a sale). It requires the use of three-letter paths like /tmp.
(Related fact: While Windows is still as bad in that it gets its own things wrong, at least they weren't tied to POSIX's filesystem layout)
There's POSIX, too. In practice, divergences are plentiful.
Differences among current browsers are more among performance and experimental features
The fact that are huge web tables meticulously documenting feature compatibilities across browsers implies differently.
Besides, a lot of web standards are done post-facto. I don't see the situation as being any better than POSIX. It might even be worse.