I agree, though I wouldn't say it's the pace of development so much as the change in approach. .NET Standard made sense as a transition plan, but then was effe

I agree, though I wouldn't say it's the pace of development so much as the change in approach. .NET Standard made sense as a transition plan, but then was effectively abandoned. I understand that the focus went to .NET 5/6, but the effort is incomplete! Using a .NET Standard 2.0 project in .NET Framework sometimes works, and sometimes results in obscure build errors -- where you then are diagnosing why you are getting the wrong versions or errors loading packages System.Net.Http.Formatting or System.Buffers. I think there's also a bunch of hacks underlying a bunch of this stuff -- for example there will be a nuget package with version 4.3.0 that contains a .NET assembly with version 4.1.1.3 in a .dll with file version 4.0.0.0 -- and it's absolutely frustrating and infuriating. In theory you can also create a project that multi-targets .NET framework and .NET core, but in practice, while I've got this to work, it's an adventure every time and most often I just give up as it's not worth the time-sink. It kind of seems like the official migration path is just "stop everything, port to .NET 5 and you'll be good". But that's not really practical. Indeed, my experience on pure .NET Core (3.1) or .NET 5 has been very good thus far -- including easily building cross-platform native apps. It's just that the reality is there's still a lot of .NET Framework code. The other big challenge for us is in delivering apps that run on customer systems. Doing the switch to .NET Core/5/6 means we have to decide on: increasing from shipping a 5MB to a 45MB app (runtime included); requiring .NET runtime is installed (and handling auto-update failures when it's not); modifying the installer to install if needed (again handling failures). This is all tons of work, and a tough sell when we have a multi-year backlog of bugs and feature requests it has to compete with.