If you mean at the bottom of the wasm, the the answer is, those won't be legacy APIs. The direction we're heading is to provide POSIX compatibility as an emulation layer on top of a cleaner foundation, rather than just doing POSIX at the base layer.
If you mean that all Wasm engines today are implemented on top of traditional operating system APIs, then yes, that is how things will often work, but that's ok. What really matters is how the virtual platform works. We don't have to expose things like "the filesystem namespace" directly to wasm, even if it's present in the host. And if we don't expose "the filesystem namespace", then we don't have the associated problems, even if the underlying host has them.
> The direction we're heading is to provide POSIX compatibility as an emulation layer on top of a cleaner foundation, rather than just doing POSIX at the base layer.
What's that "cleaner foundation"?
Next thing is: POSIX is the legacy stuff. If it's there nothing will change.
And not even to mention that the stack is going to look something like:
Hardware >> Hardware emulating some ISA (e.g. x86) >> C abstract machine >> POSIX >> VM emulating some ISA >> "container" emulating POSIX >> WASM VM >> emulation of POSIX APIs >> legacy applications written for some ISA & POSIX
That cleaner foundation is shared-nothing linking, capability-based security, virtualizable APIs, and more, and a WASI organized around things like streams as first-class types.
The goal is to build a new platform. Initially, that looks like adding layers on top of existing platforms (which, as you say, already have multiple layers). If we succeed, then we get to start taking out some of the layers.
Don't get me wrong, WASM is a nice idea with some nice properties. But WASI isn't a real improvement to the status quo in general.