That’s what JVM promised! They just made Java so there would be at least one familiar-looking (to C++ devs) language for it. Indeed, there are quite a few JVM languages out there, just not as many as some had hoped in 1995.

The JVM executes Java bytecode, which is a compilation target for Java and many other languages. In this regard, architecturally it is exactly the same.

Kind of - it was designed for Java so other languages were suboptimal for a long time, especially dynamic ones. Combined with the low quality of Java application servers and tooling, that approach was unpopular by the time things like InvokeDynamic matured and then Oracle’s licensing moves gave a lot of places reason for caution.

The biggest problem when compiling to JVM bytecode isn't dynamic languages - even if they are slower, it's tolerable. It's stuff like C++, where the whole point is being fast, but JVM simply lacks the necessary primitives to compile to.

Scala, Kotlin, Groovy proved that JVM can be used as a compilation target. Same was proven with Iron* languages on CLR. How is it different this time?

It can run "anything" ... so long as someone has set up that project to correctly compile to a wasm target. "docker build" lets you build a package out of any software, without having to know much about it. "setting up a compiler for a new project, given the source code and maybe a separate toolchain for some other target that works", is a much more involved task.

There is no world where people are just grabbing an existing app and saying "hey, I'm gonna drop this into my wasm runtime real quick"