And the strategic priority of those business units has been to take advantage of all the performance improvements that have come out of Midori toolchain into Core CLR/Native AOT toolchains, while exposing MSIL features only available to C++/CLI to C# as well.
Just like Rust can take advantage of the LLVM IR features used by clang, so does C# in regards to the MSIL used by C++/CLI.
Given your interest in C++/CLI, I wanted to give some clarification in regards to its relationship with .NET platform as a whole.
Indeed, there have been historical influences from Midori, C++/CLI, CoreRT[0], .NET Native/UWP and work done that got merged into earlier releases of .NET Core (up until 3.1), in particular, Span<T> and compiler optimizations.
However, pretty much all work done since Core 3.1 is independent, rather than "migrating of features from". The last and only exception would be NativeAOT which still uses project RedHawk name in some places in the code that haven't been renamed, referring to Midori and .NET Native (because NativeAOT has started with a big chunk of the codebase from the latter). But NativeAOT aside, pretty much all .NET features are exposed through IL and surrounding metadata, making it possible for any language to target these (rather than being related to C++/CLI), even if initially designed with C# in mind.
As far as I'm aware, C++/CLI itself uses MSVC to compile C++ code and then just generates bindings and glue code with other .NET assemblies, embedding itself into final .NET assembly produced that would use it. It did not target CIL with C++, like that new project for targeting CLR with Rust does, but rather CTS which is a quite old concept at this point. It is also limited to Windows only[1].
So the more accurate comparison would be between projects that produce .NET assemblies containing IL and projects that produce LLVM bitcode files containing LLVM-IR.
As a user I know C++/CLI, since it was initially released as Managed C++ in .NET 1, replaced by C++/CLI in .NET 2.0.
They have two ways of compiling code, fully managed, meaning pure MSIL, where the Assemblies are considered as safe as other .NET languages by the PE Verifier. In this way, some UB behaviours and not so sane stuff from C day's, is forbidden in C++/CLI and will trigger a compilation error.
Mixing in native code. In this way everything from C++ is allowed, the resulting Assembly will be a mix of MSIL and native code generated by the Visual C++ backend, and will fail verification as a safe Assembly, being only allowed in unsafe code contexts.
My reference to it, is because until the improvements started in C# 7, the only way to make use of specific CLR low level capabilities, was to either do Reflection.Emit(), or reach out to managed C++/CLI.
You are fully aware of this, but many keep forgetting MSIL was designed for C like languages as well, and just like the hyped WebAssembly has all the necessary features to take full advantage of it.
Just like Rust can take advantage of the LLVM IR features used by clang, so does C# in regards to the MSIL used by C++/CLI.