CLR sandbox should not be considered a meaningful security boundary at this point. CAS and partial trust are both officially obsolete.
The problem is always complexity. It can be difficult to reason about safety with so many features on bytecode level. There have been exploits using dynamically-generated methods, exception filters, and vararg handling - note the near-lack of any common patterns here other than they're all obscure features of the platform, the security impact of which wasn't fully analyzed.
For example, a long time ago, I reported the vararg exploit, which boiled down to the fact that you can have ArgIterator over an argument list containing another ArgIterator, allowing the latter to be mutated via the former. Thus, you can stash away an ArgIterator to the arguments of a function call that has already returned. This is basically the same as having a managed reference to a managed reference, and it's exactly why CLR prohibits this - but they forgot that ArgIterator is also a kind of a managed reference.
And WASM remains to be battle tested in the wild, as in the juicy target of millions of black hats out there.
Forcing internal corruption of code produced from C compilers (like doing a stack out of bounds data overwrite due to incorrenct params size) is perfectly viable.
Yeah the exploit doesn't leave the sandbox, so what. It can still be used to direct the sandboxed code to produce other outcome from the called functions.
You're conflating C++/CLI with the MSVC /clr compiler switch. They're distinct.
With /clr:pure (which produces CIL only, although it is allowed to use memory-unsafe features like pointers), the entirety of ISO C90 is supported on CLR, with the sole exception of setjmp/longjmp.
C++/CLI adds language extensions that allow one to interact with the CLR object model from C++ code. It is only needed if you need to call into the .NET standard library, or other managed libraries - i.e. if your C code is not portable to begin with.
C++/CLI is just ISO C++ plus a couple of language extensions, you know like the Linux kernel is ISO C plus GCC extensions.
I hardly see the difference.
No chip on the shoulder, just an old guy that has seen dozens of VMs since the mid-80s, delved into others from earlier decades, which doesn't buy into WASM marketing.