Not sure the ubiquity of (c)il comes across fully about standard HOT 3 CLOSED

That's a great suggestion! I'll update the docs to reflect this shortly. A few comments on what you said:

If [the library] is added directly to the standard it can only version at the same cadence as the standard

That is true, but only for libraries that target .NET Standard. However, each .NET platform can rev at its own cadence and extend the API surface of types that are part of .NET Standard -- they don't have to wait for a new version of the standard.

So this isn't completely true:

and will only be supported on other platforms when they update the platform to match the standard

For example, let's say we want add a new method on String, which is part of .NET Standard. If you're authoring a library that targets .NET Standard you can only see this API when we release a new version of the standard and you update your project to target that version of the standard.

However, we're free to expose this method immediately on .NET Core. Our friends in Xamarin might also quickly update their platform. Developers directly targeting .NET Core or Xamarin wouldn't have to wait for the standard to be updated. However, in order to author a library that runs on both, we need to provide a new version of .NET Standard.

from standard.

I could imagine lots of people wanting extra things to be part of the standard library.

So what I'm trying to convey is unless its a change to a type already in the standard; if its a purely managed type then its better being outside of the standard (as a package) as then you have immediate broad support on all current and future platforms.

Which even includes new System.* types; they are better living OOB when they can.

An example of the conflict is the new methods (TryXXX on Stack and Queue) needing to be in a new version of .NET Standard; even though its just managed code changes which if they were out of the standard could they could remain targeting .NET Standard 1.3 rather than reviving up to 1.7/2.1 (guessing on the 2.x version)

from standard.

Which even includes new System.* types; they are better living OOB when they can.

Agreed; I just tried to communicate the fine line of what we can and cannot do. I've seen some concerns from folks that .NET Standard makes it harder for us to innovate on types that are part of .NET Standard.

That's actually not true:

• Each platform can innovate independently. For BCL & runtime features, we're likely doing all experimentation and innovation on .NET Core first.
• Once happy, we're working with other platform owners to port the changes to other implementations and ship and updated .NET Standard so you can author code that works across all of them.

So .NET Standard doesn't slow that down; it simply puts a spotlight on the problem that updating multiple .NET platforms takes time, especially for ones that ship with the OS (.NET Framework).

Now, for BCL features that are net-new and can sit on top of .NET Standard we're likely building them as libraries targeting .NET Standard because it allows any developer to experiment with them, regardless of which .NET platform they are targeting.

They key thing is: we don't have to artificially try to make a new features pure OOBs; if the feature requires a cross cutting change across runtime, framework, and compiler we will be doing that with .NET Core.

from standard.