While you're correct that Unity "solved" the problem, you can't generalize their solution to things other than games. You end up needing a bunch of custom ecosystems for specific problems and when we're talking about enterprise, education, etc apps they often end up needing everything because sometimes you just end up with a massive Our Company's App that has 20 different responsibilities.

To put it another way: Adobe can ship Photoshop using Emscripten, and big companies can probably eventually ship their internal C# business apps using Uno or Blazor, but you're not going to ship either of those using Unity's stock approach without building out all of the platform APIs they stripped out and adding back runtime features that were removed. The decisions they made were perfect for games, but people building general-purpose platforms can't cut all those corners.

Unity has supported the .Net Framework (using .Net 4x) for several years...

However, they do not guarantee that the APIs in the .Net framework will work on all platforms, as some of them are still Windows specific.

https://docs.unity3d.com/2019.1/Documentation/Manual/dotnetP...

Unity uses normal C#. They switched to using the Rosyln compiler several years ago. https://yadiyasheng.medium.com/confusing-threesome-in-unity-...

They do take the IL generated by Rosyln and convert it to executable code using their own custom transpiler.

I mean the new "DOTS" stuff: Burst compiler, the HPC# language dialect, new ECS, and "Project Tiny". All except Project Tiny is being built mainly to improve performance, but it also benefits the web as target platform.

This is basically the same thing that Android did with Java. I think it’s probably best to pick a productive language and solve the problem from there. Low level languages are rough to work with when compared to what you get from unity.