One of the problems here is that C# and F# interop isn't always as easy as the article implies. F# has a lot of types which, when exposed in a public API, are ugly as sin in other .NET languages.
That issue is not F# or C#'s fault - it's a limitation of the expressiveness of the CLR's type-system (it doesn't support higher-kinded types, varadic type parameterization, or non-typename type parameters).
The hope and the expectation is that the CLR will gain support for first-class representations of F# concepts to allow for greater interop with C# scenarios, but the CLR's development has always been tied to C#, with other CLR languages like VB.NET and C++/CLI only exerting minor influence on the CLR's design with most of their language-specific idiosyncrasies being handled by library-code and compile-time tricks instead (e.g. VB.NET's "On Error Resume Next" statement is implemented by having the compiler wrap each individual statement in a try/catch instead of having the CLR specifically support it (though in this specific case that's probably a good idea as OnErrorResumeNext is a horrible idea I'm sure we all agree).
Minor correction, only Managed C++ and C++/CLI have the full power of the CLI, many of the performance improvements in C# have been related to exposing those MSIL capabilities to C# as well, which before required generating bytecode directly.
Which is kind of ironic given how they usually leave C++/CLI out of the picture, including the cross platform story.
Did you check the recents blog posts about C#12? Clearly the team has ran out of ideas for meaningful improvements to the language, while ignoring discriminated unions which is the most important concept missing in the language.
I’m not arguing there is more important stuff, but DUs would enhance the language on a wide, fundamental level, accelerating a lot of other advancements.
The only thing I really missed, has been adopted during the latest years, pattern matching.
Languages are not used in isolation, great IDE experience, and having mature libraries for every use I can think of, is more valuable than grammar and semantics.
Also a reason why I would rather do FP in C++23 than Haskell, even with all the warts and paper cuts it entails, ecosystem.
If only the tooling was at the same level as C# and Java.
Additionally, they add friction to a development stack, now everyone needs to be confortable with two language stacks, and most of the time it isn't really worth it.
its because they are easy to do in C# without explicit support, but the proposal is still in the works, but they argue a lot about the syntax and about exhaustive type checking for all the edge cases.