DbProviderFactories. In .NET Standard 2.0 we added almost all of the primitives in ADO.NET to allow O/R mappers and database implementers to communicate. Unfortunately, DbProviderFactories didn’t make the cut for 2.0 so we’re adding it now. In a nutshell, DbProviderFactories allows libraries and applications to utilize a specific ADO.NET provider without knowing any of its specific types at compile time, by selecting among registered DbProviderFactory instances based on a name, which can be read from, for example, configuration settings.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

Yes, I'm the one who actually implemented the code in .NET core for this

The main problem is still that you have to register something and as we needed something to register the factories with in netstandard 2.0, we added our custom solution, like everyone else. So it simply came too late (it couldn't be included in .netstandard 2.0 at the time).

We'll stay on .netstandard20 for now, till there are requirements to move to .netstandard2.1 but I doubt we'll do so as we can do everything in netstandard2.0 and we need the registration system we have now for netstandard2.0 code anyway so adding this is only a burden.

It's a bit sad how it all went through. For more than a year I asked for a solution for this, noone picked it up, I got sick of the delays so I implemented it, but the api reviews were a bit of a pain and the tooling to build the code was broken a couple of times, so a lot of delays and overhead over nothing, which caused the situation that it couldn't be added to netstandard2.0 (but I doubt they'd added it at the time if it was on time tho).

Frankly, the factories in netstandard2.1 is nice, but as .net full is going to stay on netstandard2.0, and everyone has their own custom factory registration already (to support netstandard 2.0), I doubt it will be used much.

(this in case you're wondering whether we'll add support for this particular API in the .netstandard build of the runtime).