Again, you keep bringing these up, by they are not the same thing as WASM.
Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs; it requires per-language support for them and works in terms of program source.
The CLR's C++ support is nothing like WebAssembly C++- you either FFI to native code, bypassing the VM, or you compile a limited subset of C++ to unverified bytecode- and the latter doesn't support newer language standards and is being phased out.
WebAssembly solves both of these problems- existing compilers for any unmodified language can target its standard binary interchange format the same way they would target a hardware architecture, and run within its sandbox. WebAssembly doesn't need to add support for them, or know anything about their source form.
Besides chrisseaton's answer, not only is C++/CLI already compatible with C++17, it will be part of .NET Core Windows variant, because it was yet another reason why we wouldn't migrate away from .NET Framework.
WASM in its current form is still quite limited forcing language runtimes to bring along features that other battlefield proven solutions support out of the box.
C++/CLI is already full of incompatibilities with C++17 (and C++14, and C++11), and there are plans to cut off C++/CLI support with newer standards. Existing support is mostly by accident.
Meanwhile "must distribute a runtime with the app" does not affect the language at all, and indeed applies to these other solutions as well.
LLVM bitcode is far worse than WASM bytecode as a standard binary interchange format. It is intentionally non-portable and unstable by its designers.
Google tried using it for this purpose with PNaCl and it wasn't great. Apple makes it work by strictly controlling the target hardware they use it for, and with massive investment in the toolchain.
That's more a criticism of C rather than LLVM. Bitcode isn't as portable or stable as JVM bytecode because real world C programs use processor specific intrinsics, make assumptions about endianness and word sizes, embed assembly etc etc. LLVM is designed to support all real C programs, which means it can't be entirely portable.
Wasm today is a toy hardly anyone uses. It can't run many real world C programs which means they'll need to be "ported" to the subset of C wasm supports. Well, if you're willing to work with that constraint you can constrain bitcode in the same way.
By the way Graals LLVM support can execute multiple bitcode versions, with seamless and fast language interop, and it virtualises execution so that e.g. a subset of x86 assembly can be cross compiled on the fly to other arch's. It's needed because so much real C doesn't target an abstract machine but real CPUs.
Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs; it requires per-language support for them and works in terms of program source.
The CLR's C++ support is nothing like WebAssembly C++- you either FFI to native code, bypassing the VM, or you compile a limited subset of C++ to unverified bytecode- and the latter doesn't support newer language standards and is being phased out.
WebAssembly solves both of these problems- existing compilers for any unmodified language can target its standard binary interchange format the same way they would target a hardware architecture, and run within its sandbox. WebAssembly doesn't need to add support for them, or know anything about their source form.