CoreCLR will be nice for Unity with the 2x performance improvement.

I wish Microsoft had moved to it quicker and Unity wouldn't have had that lull on Mono 2.x .NET and had to build IL2CPP.

When IL2CPP was being rolled out it was quite impacting to build size and actually making iOS builds for a while in 2015 from like March to summer was not workable for months. Now they have Android on it and it works well but keeping all that up to date is cumbersome for a smaller tech/engine team.

I still would love a C++ engine/lib like they were going to do back when Apple was forcing AOT instead of JIT languages around 2010 [1], but having a C# engine that can be comparable in performance is killer.

As long as this update is smooth and is truly faster that would be welcome. It was harder to trust Microsoft before during the Mono/.NET disconnected period so Unity treaded carefully but after Microsoft bought Xamarin and went .NET standard/core it seems like they are embracing and not extinguishing. Microsoft's new focus is Azure and .NET core/standard help expand that as well as its use by Unity (always a C# champion) and even Unreal Engine possibly which some have attempted [2]. If Unity switches to .NET core/standard possibly Unreal Engine will be compelled to add it natively.

[1] https://blogs.unity3d.com/2010/07/02/unity-and-ios-4-0-updat...

[2] https://mono-ue.github.io/ or https://github.com/xiongfang/UnrealCS

They put up their editor source code on Github recently (https://github.com/Unity-Technologies/UnityCsReference), and originally it also included the full source to their runtime garbage collector, which ended up being the standard open source C++ boehm collector (https://github.com/ivmai/bdwgc) from the 90s.

Unity should replace it with a reference counting object management system, or update to a newer garbage collection technique to minimize the inadvertent sweeps that cause huge choppy frame rate drops.