Hi, thanks for the question. No particular reason: it might be the one we settle on eventually. For now, Wasm hasn't been in my focus and thus hasn't received any work. When it does become a focus, it might rather be brought in as macro assembler kind of thing, based on the assumption that effectively all Wasm bytecode has been emitted by an optimising compiler and thus trying to reoptimise it is not worth it.

Maybe Cranelift might offer that out of the box? If so, it'd be a great choice. If it doesn't, or if the only lever to pull is simply a runtime "how much optimisations should we do" one then Cranelift might not be such a great choice, since we'd want to avoid bringing in big and heavy dependencies that only use a particular subset at runtime.

Sure sure, but the ECS-style layout doesn't sound like it applies to a WASM engine like it does to JS.

Yeah, only place for ECS-style layout would probably be in the interpreter, but a Wasm interpreter might not be the thing one wants to do.