All of the AccessControl types were moved higher up in the stack since they were windows specific. The extension methods were designed to offer source compatibility for folks moving from .NETFramework to .NETCore (or .NETStandard). We cannot forward to extension methods from the lower-stack types (no such technology exists), and the members cannot exist on the lower stack types without bringing all of the AccessControl types down in order to match the method signature, even if we wanted them to throw PlatformNotSupportedException.
any code compiled against Framework that uses GetAccessControl/SetAccessControl on Mutex, will not know it actually needs to call into ThreadingAclExtensions instead
Compiling for .NETFramework and running in .NETCore is not a perfect thing and in most cases the IDE will warn you when you try to do this. Even with Microsoft.Windows.Compatibility, it will only work when the types or members exist in .NETCore. That's not the case here: these members do not exist and these exceptions are by design.
Microsoft.Windows.Compatibility does enable compiling a .NETStandard library and using these APIs. It will do the right thing when run in both .NETFramework and .NETCore. The extension methods were added via the Compatibility package to .NETFramework. If compiling for NETStandard works for you that would avoid this. If you can't compile against .NETStandard nor .NETCore, then you could directly invoke the static extension methods which would also work everywhere.
The only real way to fix this is to push AccessControl types down, all the way to CoreLib. Perhaps folks would have more of an appetite for this now that we have the platform compatibility analyzer. , what do you think?