The problem is that the CLR comes with the the C# memory model and garbage collection.
If you don't want that, then what's the point of the CLR? You can't use most of the .Net API without objects and garbage collection.
That basically rules out any kind of real-time application. The more modern garbage collectors allow soft real time applications, but you still can't do things like use the CLR to run an airplane.
If you want to use the CLR for a real-time application, you basically have to replace most of the .Net API with a completely pointer-based version, and consider implementing your own real-time memory management model.
At that point, you might as well target your language to compile natively and use standard libraries in the operating system.
The CLR was designed to support C and C++ as well, apparently new generations don't have a proper clue what CLR is all about.
Also contrary to WASM, there are real hardware devices actually shipping stripped down versions of it.
And if real time is a concern, then not using a real time OS is already the big first mistake, there is nothing here for WASM to prove, only to catch up with existing battle tested solutions.
The problem is that the CLR comes with the the C# memory model and garbage collection.
If you don't want that, then what's the point of the CLR? You can't use most of the .Net API without objects and garbage collection.
That basically rules out any kind of real-time application. The more modern garbage collectors allow soft real time applications, but you still can't do things like use the CLR to run an airplane.
If you want to use the CLR for a real-time application, you basically have to replace most of the .Net API with a completely pointer-based version, and consider implementing your own real-time memory management model.
At that point, you might as well target your language to compile natively and use standard libraries in the operating system.