SslStream TLSv1.2 client instance in MMC snap-in without modifying Windows config: can it be done?

Question

We have a legacy MMC snap-in developed with the MMC Class Library. The snap-in assembly targets .NET Framework 4.7.

We have a requirement to create TLSv1.2-enabled SSL client connections from the snap-in. Using a freshly installed Windows 10.0.19042 (the current Hyper-V "quick create" Win10 dev image), the max TLS level of connections created by the snap-in is TLSv1.0. OTOH, a console or windows program assembly targeting .NETv4.7 running on the same machine (but not hosted by MMC) creates TLSv1.2 client requests perfectly.

We discovered two unsatisfactory ways to modify Windows which allow the snap-in to create TLSv1.2 connections:

1. By modifying the registry.
2. By modifying MMC's application configuration file (mmc.exe.config), merging the following fragment: <runtime> <AppContextSwitchOverrides value="Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols=false;Switch.System.Net.DontEnableSchUseStrongCrypto=false;Switch.UseLegacyAccessibilityFeatures=false;Switch.UseLegacyAccessibilityFeatures.2=false;Switch.UseLegacyAccessibilityFeatures.3=false"/> </runtime> (what's the deal with the MD previewer, I hope the post looks better!)

Since both options may induce unforeseen side effects in other programs, they are not generally viable. Why doesn't this "just work", especially given that we have followed all the known "best practices"?:

• SslStream connection initiation methods do not specify the SslProtocols parameter.
• The snap-in assembly targets .NET 4.7 as per documented guidance.

Useful code modifications have eluded us as well, such as explicitly specifying SslProtocols.Tls12 (this fails with ArgumentException).

This seems like a bug with the way mmc.exe is hosting the CLR.

Is there really no way to do this programmatically and in-proc? Must we force users to perform Windows hacks? If so can we at least assure them that the SChannel client always negotiates down from TLSv1.2 to TLSv1.0 in the legacy cases, so their other programs are "probably OK"?