Reposting as a new issue for visibility.

Are there any actual blockers which prevent at least limited support of 4.6.1 as a part of .NET Standard 2.0?

I needed that and while I know that 4.6.1/Standard 2.0 situation is messy in .NET in general, I've:

1. patched CLR Loader to compile for net461 (LPUTF8Str -> IntPtr with manual conversion, ValueTuple -> Tuple),
2. referenced ValueTuple and InteropServices in Python.Runtime.csproj,
3. made a build step to copy netstandard.dll assembly to the OutDir,

and only if I switch the target framework to net461 for Python.Runtime.csproj, then I am able to run a simple hello world successfully from Python in a 4.6.2 environment. If I switch target back to netstandard2.0 -- the assemblies disappear from the output, and even if I add them back - I for some reason get errors on loading them which I currently am not sure how to resolve:

Failed to initialize pythonnet: System.TypeInitializationException: The type initializer for 'Delegates' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=0.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
   at Python.Runtime.Platform.LibraryLoader.get_Instance()
   at Python.Runtime.Runtime.Delegates..cctor()
   --- End of inner exception stack trace ---
   at Python.Runtime.Runtime.Delegates.get_PyGILState_Ensure()
   at Python.Runtime.Runtime.PyGILState_Ensure()
   at Python.Runtime.Py.GIL()
   at Python.Runtime.Loader.Initialize(IntPtr data, Int32 size)
   at Python.Runtime.Runtime.Delegates.get_PyGILState_Ensure()
   at Python.Runtime.Runtime.PyGILState_Ensure()
   at Python.Runtime.Py.GIL()
   at Python.Runtime.Loader.Initialize(IntPtr data, Int32 size)

I am not sure how to properly make netstandard2.0 assembly to reference and copy those DLLs properly for running on 4.6.1, would appreciate some insight on what I am doing wrong.

If this is reasonably solvable, will there be opposition to allowing 4.6.1 (with a strong recommendation to update to 4.7.2) potentially, if, say, I submit the PR fitting the requirements?

Also, outside of that, are there any blockers for going even lower theoretically (if I don't need to support anything else than .NET Framework)? Not as a part of the upstream/mainline.

Originally posted by @Metadorius in #1299