They are finally clearing things up with .NET Standard 2.0, which is like the One Standard to Rule Them All. I consider .NET Standard 2.0 and its related implementations, along with Visual Studio 2017, to be the first real production-ready set of standards, tooling, and frameworks. It's what .NET Core should've been from the very beginning.
Now we have so many different versions to follow that I am really worried it will be impossible to keep any level of uniformity and compatibility between them. There are .NET Standard, Canadian, .NET Core, Mono, .NET Framework with .NET Standard's compatibility shim and .NET Core tooling. I hope I didn't forget anything else. It's already crazy as it is.
I am a long time .NET developer and I also was confused in the beginning of .NET Core about what was going on and I think their rush to release an unfinished product was to blame.
Ahh yes, good old .NET Canadian. It's exactly the same as normal .NET, except all methods and properties referring to 'Color' have been changed to 'Colour'.
As a Canadian .NET developer, this has caused me endless headaches when trying to pull in American graphics libraries via NuGet.
I thought you might have been taking about the .NET Foundation but made a typo and it got mangled by autocorrect.
Regardless, I agree with your point. The name of things in the .NET ecosystem is a bit confusing right now.
Most of the runtimes were developed evolutionarily for different system niches, well before .NET was given the option to be open source by default. .NET Core tried to reboot some of the "organic" evolutionary tech debt of several runtimes it was directly replacing/built from (the Silverlight runtime; the old Windows Phone runtime; the WinRT .NET runtime).
«Python is a great example, since you have your standard library with some rather carefully selected OS-specific APIs and then you got a bunch of runtimes all under the same version; no confusion whatsoever.»
Python still has multiple runtimes and some small amounts of confusion: CPython, Pypy, Stackless, IronPython, Python on Parrot... They don't/haven't all support the same version of the language and CPython has always been the "official standard" version, but Python is an example that no language is entirely immune from multiple runtimes either.
«I am a long time .NET developer and I also was confused in the beginning of .NET Core about what was going on and I think their rush to release an unfinished product was to blame.»
I don't think .NET Core was in a rush to release an "unfinished product", though it may seem to for a long term .NET developer. .NET Core has been the first runtime allowed to develop out in the open, as open source. It took about the same development time, I'd estimate, as the most similar projects you could imagine. But instead of showing up "out of nowhere" in VS 2017 Preview 1, mostly complete, we saw a lot of the little and big decisions along the way. Because it was .NET and promising big things I think .NET Core got a lot more early scrutiny by the .NET developers in what was closer to the equivalent of Python's "PEP development" phase, to use Python as the analogy, than .NET Developers had ever seen before.
Think about it in a web sense. We have ECMAScript which is slowly being added to. ECMAScript is the specification and it has it's own version. Then we have browsers that "implement" that specification and they also have their own version numbers because they aren't ONLY building something to handle ECMAScript, they are building other features on top of that.
So in terms of .Net Core vs Mono for example, while they both may implement the .net standard, they can also have their own features unique only to one. It's not a straight implementation with nothing else added.
Now say you are building a website and you want to target all "modern" browsers. It doesn't matter what version of ECMAScript is up to, it matters what each browser has so far implemented. If you are building a library for .net, then you can say "OK, I implement this standard. That means Mono Version X and .net Core version Y can be used". Similar to how you would say "You need Firefox version X or Chrome verson Y to use this feature".
All big corporations are like that.
UWP, Xaml, and Mono could then become libraries as expansion on .Net core.
That doesn't help anyone that thinks UWP itself is a "fad" (as in the GP comment) think .NET Core might not be a fad too, but UWP seems to be here to stay despite how many ancient developers seem to have "Win32 or Die" tattoos.
They could/should just hire a single person who manages all the naming and it would probably pay back 1000x in productivity increases.