Sounds like you're really poorly reinventing Inferno. I don't even understand why you would need WebAssembly in this hypothetical scheme. Container namespacing

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?