As we know, Unity does not use the latest and greatest Mono project code from http://www.mono-project.com, but an internally-customized version with some internal bug fixes.

As an unfortunate consequence of how various components of the Mono Framework are licensed, Unity Technologies has only been able to update Mono on an infrequent basis. The occasions on which this task were accomplished was with the release of Unity 4, when they upgraded to Mono 2.6, and shortly afterwards version 2.6.5 back in mid-2010, which supports .NET 2.0/3.5 features. But, at the time of publication, the latest version of Mono, version 4.0, was released in May 2015, and supports .NET 4.5 features. This puts Unity's implementation about 5 years behind in terms of C# language and .NET framework features, which has drawn the ire of many Unity developers.

Unity Technologies has suggested there might be a Mono upgrade sometime in the lifecycle of Unity 5, but the last official update on this subject was back in August 2014. The Unity roadmap (https://unity3d.com/unity/roadmap) places it in the "Long and Uncertain" timeline, and Unity v5.2 was released in early September 2015, which did not include this upgrade. So, it is difficult to say when Mono will be receiving its much-needed upgrade. Unity Technologies has also been working with Microsoft to bring replacements to some Mono Components (such as upgraded versions of the static, JIT, and AOT compilers, as well as the CLR).

Meanwhile, Unity Technologies has been working on the problem of long-term independence from these third-party dependencies for a while. With the release of Unity 5 they unveiled a new approach for script code compilation, which started as a way to provide improved scripting support for WebGL-based Unity applications, but has also been adopted as the main solution to these woes: IL2CPP.

IL2CPP is shorthand for Intermediate Language To C++, and comes with its own .NET runtime that can be rolled out to multiple platforms. The basic idea is that C# script code will be converted into an intermediate language and then converted again to C++ during the build process. The resulting C++ will be pushed through one of several available platform-specific compilers to support cross-platform capability, taking away the burden of having to create and manage their own compilers.

This process will be mostly disguised from the user, and naturally there will be a loss of control as the code is pushed through multiple "code filters" with varying levels of optimizations. It remains to be seen if they allow some hooks to control the compilation process for advanced developers. The Editor is still expected to run on the C# .NET runtime for faster development iteration.

The suggested benefits of this approach include performance enhancements (since even near-native code generated by the JIT compiler still pales in comparison to statically-compiled native C++), faster porting and feature development for the Unity Engine, and improved garbage collection. The first platform to get the IL2CPP treatment in Unity 5 is WebGL, and will eventually be pushed to other platforms as the system matures, and becomes more reliable.

Why doesn't Unity Technologies just provide a C++ API for Unity? One can only speculate, but it's a pretty safe assumption that Unity supports a very large user base of developers who would be uncomfortable working in C++ directly. Losing the accessibility of C# and UnityScript would result in a very different product. Long-term, it would likely split the customer base into two camps, which rarely bodes well since whichever one brings in the most revenue will become the one that is supported to a greater degree, leaving the other to rot (as an interesting analogy, games typically suffer from the same problem, as expansions and map packs tend to segregate the multiplayer user base).

In addition, there are many .NET languages that share the same intermediate code after compilation (CIL), and they have a common binary interface, which makes it orders of magnitude easier to support cross-platform development and multiple libraries than with C++. Presumably, IL2CPP is a compromise for these concerns.

So, to make a long story short, there are a great many changes going on with the underlying Unity Engine and it's too early to say whether the IL2CPP approach will work sufficiently well on all platforms to keep feature parity and ease of deployment. One thing is for sure; the next couple of years of Unity development will bring some interesting transitions!