It would be hard because traditionally most of our hardware relies on the register memory model. Implementing a hardware stack can be done but there are very few silicon CPUs like that thus a lot of the research which has been done on getting register machines up to speed in terms of caching and speculation could be difficult. Then there is the fact that webassembly doesn't use branch labels rather it uses blocks, which AFAIK have never actually been used on traditional CPU hardware.

People have tried to create high level language CPUs but often failed in terms of performance. An overview can be found here: https://en.wikipedia.org/wiki/High-level_language_computer_a...

Maybe, however remember that you then need to buy new hardware to use new WASM features.

Also WASM isn't really ideal for interpretation, this could make implementing the CPU harder (however I have no clue about implementing CPUs, so this is just a guess).

What would be the advantage? Performance? Probably not much after JIT compiling WASM to native machine instructions. If there is an actual problem there, I guess it would be better to just add new native instructions that support WASM semantics. The JIT can then use these instructions if available.

Right now WASM can't do much without a runtime, so I think a WASM-only CPU is probably infeasible for some time.

No idea, although it might defeat the purpose a bit (which doesn't mean nobody would do it)

This was already done for the JVM. It was an utter failure, and not economically viable at all.

As the OP said: this is reinventing the JVM, just worse. Including making all the mistakes again.

(At least for the server, that is. I see a great future for WebAssembly on client systems, where the JVM can be considered a failure.)