Interesting conversation; thank you all.
There doesn’t seem to be anything in WASM (present and proposals I am aware of) that would be hindered in the Mill. In particular, translating to WASM from C/Rust/etc should work just like on any other machine. Naive JITing from WASM vm to Mill native should be slightly simpler on the Mill, because the stack maps naturally to the hardware belt. Non-naive JITing would be more complex on a Mill because the stack code would have to be first analyzed for inter-operation dependencies so that independent calculations can be scheduled to execute in parallel. That analysis would typically involve a translation to SSA-form, from which our existing schedulers can produce multi-instruction bundles. The benefit would be much better runtime at the cost of the extra analysis time, typical of JITs in general.
Where x86 and other ISAs with page-level protection have to allocate a fixed page-granularity sandbox, on the Mill each WASM job would have a unique turf and would use the Mill native byte-granularity protection, and portal calls for access to libraries. This should economize on address space and TLB thrashing when compared to page-based systems. I would also expect that the Mill approach to shared libraries would make it more difficult for an attacker to leak out of its sandbox into the shared space.