That is pretty much the point I was trying to make. Emscripten has been out for a long time already, large C++ projects such as engines such as Unreal (3 months) and Unity, (1 year) have already been ported, it has taken Blazor many years (3 years?) later to make a port and it is still experimental whereas the others are in a production worthy state. It is because of this sluggishness of porting such a massive codebase that I believe Microsoft is going to be losing interest in .NET technology.
Component based, as in object-orientated? I am not saying that C++ or C vs Java or C# are better languages. In fact I tried hard not to mention languages at all and refer entirely to their underlying platforms, (.NET, native, JVM). This is the crucial part to their success. The actual languages themselves are barely important.
Again, it isn't how fun or nice the language is to use. I am talking about lifespan. In theory it is possible to make a version of Lua that has a C#-like frontend and the exact same benefits would be seen. The fact of the matter is that the .NET VM and supporting platform is many, *many* lines of code, many of it very platform and architecture specific, whereas the entire Lua VM is about 20 source units of ANSI C. This is why I predict that Lua will outlive VB.NET, C#. C++/clr, IronPython and other .NET based languages.
So both of these achieve the same result in very different ways. The first one converts the .NET bytecode (IL) into C++ code which allows Unity to stay quite a bit more portable (It still requires bohems-gc but that is pretty portable these days). Whereas the AOT is basically just a JIT that stores its generated binary. This is less portable and only works on a very limited number of platforms.
So out of these two methods, the Unity one is potentially best but is certainly very tied to their engine and a generic i.e Web app will be very unlikely to work with it directly.
Will Microsoft adopt this approach? If they did, I could see C# living on (not necessarily the .NET Framework, but certainly the C# language itself).
I am not attacking C#, far from it, I would much rather use it than risk the safety issues found in old obsolete C++ or C. However, due to issues with lifespan, I find there is very much a lack of suitable alternatives (Modern C++ is actually pretty good these days and I generally stick with that).