Yeah, except that usually WebAssembly is placed as being innovative in supporting C and C++.

Bytecode for C and C++, is even older than the CLR, and before the browsers, there were a couple of J2ME competing stacks that used C and C++ instead.

Again, the innovative part is the embeddability of the bytecode/VM. The CLR is not designed to run malicious code and still be safe (It had very interesting work on that with Midori, still).

The innovative thing with wasm is half political (that is it is socially free to implement and use) and half the lightweight reliable sandboxing.

It is perfectly possible that there is a subset of the CLR that would have been a better Web-Assembly than this WebAssembly, but the CLR chose different trade-offs so it isn't.

One of WebAssembly main distinguishing features is that it can compete with eBPF in term of safe embeddability.

WebAssembly is indeed innovative, especially in the field of security. Another great concept is normalized control flow graph of WebAssembly byte code - it significantly simplifies the job for interpreters and JIT compilers at run time.

But WebAssembly (wasm32) code density is not the world's best. Comparing to good old x64 it goes at 1.42/1.0 ratio which is still tolerable. I hope someday we'll get a more dense instruction set like ARM's Thumb.

So what does it offer versus CLR, IBM i and z/OS security models?