The reason processes aren't enough for isolation is primarily because of the large (and growing) number of syscalls, especially for complicated, bleeding-edge s

The reason processes aren't enough for isolation is primarily because of the large (and growing) number of syscalls, especially for complicated, bleeding-edge subsystems, exposing significant kernel surface area that's susceptible to exploits when kernel bugs are discovered. The WASM ecosystem is recapitulating this stage of affairs by increasing the surface area with external systems in the same fashion. Unix processes combined with seccomp (or pledge) to reduce exposed kernel surface and landlock (or unveil) to limit filesystem access puts you back at square one. Processes running WASM interpreters should be leveraging those interfaces, anyhow. What really differentiates WASM is the "compile once, run anywhere" portability allure. But we live in an age of open source (in the literal sense). Ecosystems like Go and Rust assume source code availability; binary blobs are the exception. There's not much of a difference between C, Go, or Rust textual source code on the one hand and a WASM binary on the other; both are going to be compiled to native code by the downstream user. When you have the source code available to compile, then standards like POSIX should suffice. But they don't (at least not completely), because people are always chasing newer features that various environments invent to differentiate themselves. I don't see how WASM resolves that fundamental dynamic. Though I don't deny there are marginal benefits, just like there were with the JVM, which in many niches effectively resolved the Unix/Windows portability issue, allowing people to migrate platforms easier as preferences and requirements change.