Userland doesn't have any semblance of I/O. WASI doesn't support arbitrary syscalls, so running containers would not work in WASM.... I'm not seeing your solution to this. Docker and would-be-WASM-docker would have very, very different scopes and thus would not be comparable.
Both sides of the Wasm env are userland, you can expose any method you wish into the Wasm environment. You don't even need WASI, its just a crutch for programs that expect libc.
Wasm is two things, CFI and capabilities, everything else is an implementation detail.
Your definition of a container is too limited in scope. You don't understand what I or Solomon Hykes are saying wrt Wasm and isolation. I tried to help.
What's important to understand is, Docker exists because Oracle made Java too scary to touch, thanks to big ongoing lawsuits against Google, and demanding royalties just for running a JVM server. Also the JVM is fast, but it's slow enough that it's within striking distance of a full cgroup, running a full Linux kernel.
So it made sense to just create Docker, and allow people to abandon things like jruby, and just run normal Ruby in a Docker container.
WASM is what people would have wanted when Docker was created. A bytecode format like JVM, but faster, and not encumbered by big bad Oracle's coffer-rattling.
So in other words, if WASM had existed when Docker was created, people would have just recompiled their apps for WASM bytecode, and would have also recompiled things like MongoDB and MariaDB for WASM. Things like network syscalls would be replaced by traps to the webassembly runtime.
