Preface: This solution may apply to the original issue if the faulting code is dynamically being loaded into the host process. If Azure functions are loaded through the clr_libhost, it's likely relevant.
In my case--and in several others out there apparently--the failing code using Microsoft.Data.SqlClient was loading into a native host process (as a managed plugin). On the same machine, the code works fine if the host exe is managed, but fails when loaded as a plugin with the "unsupported" error.
Looking at the load sequence in a debugger between the two scenarios provided a clue:
Standalone managed host (library load sequence) - Works
'SimpleClient.exe' (CoreCLR: clrhost): Loaded 'C:\temp\TestHost\SimpleHost\bin\Debug\net6.0\SimpleHost.dll'. Symbols loaded.
'SimpleClient.exe' (CoreCLR: clrhost): Loaded 'C:\temp\TestHost\SimpleHost\bin\Debug\net6.0\runtimes\win\lib\netcoreapp3.1\Microsoft.Data.SqlClient.dll'.
'SimpleClient.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.16\System.Data.Common.dll'.
Native host (library load sequence) - Fails
'NativeSOETestHost.exe' (CoreCLR: clr_libhost): Loaded 'C:\temp\TestHost\TestPlugin\bin\Release\net6.0\SqlClientTest.dll'. Symbols loaded.`
`'NativeSOETestHost.exe' (CoreCLR: clr_libhost): Loaded 'C:\temp\TestPlugin\plugin\bin\Release\net6.0\Microsoft.Data.SqlClient.dll'. `
Faults here when attempt is made to use types in Microsoft.Data.SqlClient.dll
Observe that dotnet uses a different loader to handle these two cases (clr_host vs clr_libhost), and that when clr_host is used, the implementation is apparently smart enough to dig into the generated runtimes subfolder to find the version of Microsoft.Data.SqlClient.dll that works (under netcoreapp3.1). Altering the plugin to use this version (manually copied/deployed) resolved the issue for us.