[maxxxxx]

I am not sure if you are going about this the right way. Instead of doing .NET standard, .NET Core and .NET full framework with overlapping functionality, I think it would better to have .NET Core as the underlining cross-platform standard. Then add WPF, WCF and whatever as separate packages that may be cross-platform or not.

The whole thing reminds me a little of the UI situation. Start with Winforms, don't improve it but start WPF (and keep Winforms), then start Silverlight, then start UWP. All in parallel instead of building on top of each other.

MS doesn't need more more frameworks, but less.

[snuxoll]

.Net Standard isn't an implementation, it's a specification. Code that targets .Net Standard is guaranteed to run on any compatible runtime that supports it.

.Net Core has API's that aren't applicable to the Windows full-fat Framework, Mono or Xamarin - you don't need or want them there.

[Rusky]

All of these API surfaces are pretty large- what is a good way to get a feel for what they do/don't offer? In particular, what are you referring to in .NET Core that you wouldn't want in Framework?

[snuxoll]

.Net Core supports P/Invoke on Linux and macOS, you aren't going to be using a library that provides bindings for libsystemd.so or whatever on Windows - this is probably one of the most prominent examples. I know there's a handful of others, but I'm having a hard time finding a good article or any relevant documentation on it.

[maxxxxx]

This sounds all good but now we are in the typical Microsoft dilemma when you start something. Core or full? Winforms, UWP or WPF? All very similar but different enough to make a move between them difficult.

[snuxoll]

You're never going to remove this choice entirely, the goal is to allow you to keep your libraries when moving between target frameworks.

[terrajobst]

In a sense, that's what we have been doing. But the challenge is that .NET Core is an actual implementation and the other .NET stacks have their own (i.e. the code base isn't shared, Mono/Xamarin/Unity are on a different train than .NET Framework/.NET Core).

For newer .NET implementations we push folks to start with .NET Core and adding their specific technologies on top. That is, for instance, what Samsung has been doing with Tizen. So if the open source community innovates in .NET Core, Samsung can just move to a later build of .NET Core in order to benefit from it. They are a pure superset of .NET Core, by construction. However, for all other cases someone needs to port the changes from .NET Core to Mono which makes it consumable by Xamarin and Unity. .NET Framework is in a similar boat, although porting is somewhat easier as the .NET Core code base originated from .NET Framework.

Since we can't (easily) move Mono/Xamarin/Unity/.NET Framework on top of .NET Core, we need a way to standardize the API set so that it's not all chaos. And that's where .NET Standard comes in.