I'd like to think one day that the non-web side of WASM could become a more deterministic and cross-platform-predictable LLVM IR. Right now it is too limited of course but as GC and threading specs come along, I can hope one day it will reach parity. Granted it isn't as low level, but that has benefits for compiler backend implementers (they can choose how they target their arch) and compiler frontend implementers (they don't have to do different things per platform). Basically, imagine if Java bytecode was developed less around OO semantics, wasn't lumped in with its stdlib by the community, didn't have encumbered JCK and other tests, etc, etc.
Edit: Changed "LLVM" to "LLVM IR" to clarify as requested.
I'm not sure your criticisms of Java bytecode are all that reasonable to be honest.
You don't have to use the Java standard library to target bytecode. Scala, Ceylon, Clojure provide their own stdlibs. Indeed not doing this is one of Kotlin's competitive advantages.
Although the JVM wants to think in terms of objects, this is only really mandated as a unit of linkage and garbage collection. You could equally criticise C runtimes for being too oriented around procedural programming semantics because they see the world in terms of top level functions and global variables. You can write non-OOP programs in Java bytecode and Eta is an example of using the Haskell Spineless Tagged G-Machine representation on top of the JVM. If your runtime doesn't have any concept of an object-like thing, then it gets rather hard to do garbage collection and certainly any kind of moving GC.
Finally, the JCK is encumbered to protect the Java trademark. We can argue about whether that's really been so useful given Android, but the principle makes sense - it's about ensuring that if someone claims they run Java bytecode, they actually can run it. If WebAssembly isn't trademarked and protected in the same way then it'll be a repeat of HTML5, where a claim of support is essentially meaningless and everyone has to constantly consult giant feature/bug tables to figure out what subset of the spec works on your particular implementation.
Now it may be that in the end everyone is OK with the word WebAssembly being more of a statement of intent than a precise claim, just like we muddle through with the word HTML5. And in reality we all know that only Mozilla, Microsoft, Google and maybe Apple will implement wasm or at least only these companies will have implementations anyone cares about. They will probably comply with whatever test suite is produced without needing legal/trademark incentives. Maybe.
> Scala, Ceylon, Clojure provide their own stdlibs.
On top of the JVM ones when targeting the JVM. E.g. java.lang.String (Kotlin too)
> You can write non-OOP programs in Java bytecode
Everything is still an object and all code is in methods. There is no way around that. Also, there are many other things like forced GC and what not that marry the bytecode to certain paradigms.
> it's about ensuring that if someone claims they run Java bytecode, they actually can run it.
And about their impls of java.lang and other base packages. And a way to make sure that licenses that Oracle doesn't like, such as non-OpenJDK-derived open source stdlib impls, are not given the tests. Other languages with compat tests publish them for all and yet aren't worried about losing their name. This is dangerous reasoning to apply to keeping things opaque.
It isn't just those big companies implementing WASM. I implemented a WASM backend for the JVM [0]. The core test suite, which I use and comply with 100%, is available to all [1].