There are plenty of languages built on the CLR [1], including variants of Clojure, Python, and Ruby. Then there's the "official" languages: C#, C++/CLI, VB.NET, JScript.net.
I suspect what's going on is that 1) unlike Java C# has actually evolved so the need for "escape hatch" languages is lesser, and 2) .NET developers want to use languages with rich Visual Studio tooling.
With the exception of UWP support (which I'm sure will come), F#'s future seems pretty certain to me. There seems to have been a lot of interest in it lately, probably fueled by the current hype over functional programming.
We can forget about UWP support, it isn't going to happen in the near future, who knows if it ever will.
"The F# team is currently focused on .NET Core tooling in Visual Studio and further support for .NET Core as it evolves. There is no ETA for .NET Native/UWP support at this time."
With UWP, Visual C++ kind of finally caught up with C++ Builder, it even has support from Blend for UI design.
MFC is mostly on maintenance and new application should use XAML + C++/CX.
C++/CX makes use of the C++/CLI extensions but it targets AOT compilation to native code instead.
The alternatives are C++ with WRL (Windows Runtime Library), basically ATL replacement, and what most Microsoft teams actually use for the UWP kernel components.
Because most C++ devs would rather use something more standards friendly, there is work in progress to eventually replace C++/CX with C++/WinRT, taking advantage of C++17 features.
Not much, throughout my career I have learned that the best path is always to only use the officially supported SDK languages for production code.
All productivity or enjoyment using alternative languages gets lost in extra FFI layer, unavailable platform documentation, lack of support on the IDEs, poorer debugging, GUI tooling and code generation.
So I only use alternative languages to learn about new concepts and ways to improve my skillset, but in what concerns production code, the golden rule is 100% SDK languages.
Going back to your question, Java on UWP is only possible via the JVM provided by CodenameOne and I think it actually makes use of the Desktop Bridge, so that rules out Scala.
Rust still has a lot to catch up with C++ for using COM in a productive way, let alone .NET based languages.
UWP is basically what .NET should have been, if they had kept the original COM+ plans instead of going with the CLR. So any language targeting UWP needs to have seamless COM support, and ability to handle .NET metadata.
Point taken; it's obviously not a top priority for them, with C# remaining the primary focus. I guess that makes sense, since so many more devs use C#.
While dissapointing, I'm sure (well, I hope :) F# support will land in VS before too long. In the mean-time, VS Code really is a great alternative
I suspect what's going on is that 1) unlike Java C# has actually evolved so the need for "escape hatch" languages is lesser, and 2) .NET developers want to use languages with rich Visual Studio tooling.
https://en.m.wikipedia.org/wiki/List_of_CLI_languages