A fully qualified type name consists of an assembly name specification, a namespace specification, and a type name.
...
IDENTIFIER naming should follow the rules for file naming. The IDENTIFIER is case-insensitive.

https://docs.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/specifying-fully-qualified-type-names

Spaces are relevant in all type name components except the assembly name. In the assembly name, spaces before the ',' separator are relevant, but spaces after the ',' separator are ignored.

https://docs.microsoft.com/en-us/dotnet/api/system.type.assemblyqualifiedname?view=net-5.0

a wildcard character (*) can be used in the assembly name specification in the permission.
...
It is illegal to replace the left part of the name with the wildcard character (for example, *.DirectoryServices)

0x80131216Error: Assembly name contains path and/or extension.

GAC задеприкейтели.

.NET Core and .NET 5 and later versions eliminate the concept of the global assembly cache (GAC) that was present in .NET Framework.

https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/5.0/global-assembly-cache-apis-obsolete

Как теперь указывать полное имя сборки?

Может попробовать внутрь machine.config засунуть codeBase:
https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/codebase-element
?

If the assembly is a private assembly, the codebase setting must be a path relative to the application's directory

https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/codebase-element

Можно ли указать просто путь в файловой системе (с file:// протоколом и/или абсолютным путём) ?

А можно ли сделать через .pc-файлы от pkg-config ?

А через имя пакета Nuget?

(Это я ещё не говорю про то, что там негде указать архитектуру...)

we can set up different assembly load contexts; this lets us load different versions of assemblies into different contexts in the same application. This was not really possible before. Second, we can unload assemblies after we're done with them. Again, this is something that was very difficult to do before.

Ну ок, а через контекст это (путь и/или архитектуру) можно указать?
можно:
AssemblyLoadContext.Default.LoadFromAssemblyPath
но мне это никак не поможет, потому что мне нужно указать путь до сборки в конфиге:

<system.data>  
  <DbProviderFactories>  
    <add name="SqlClient Data Provider"  
     invariant="System.Data.SqlClient"
     description=".Net Framework Data Provider for SqlServer"
     type="System.Data.SqlClient.SqlClientFactory, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"  
    />  
  </DbProviderFactories>  
</system.data>

Там, где type= написано. А там нет никакого FromAssemblyPath.

When you build a .NET Core application, the compiler also produces some Runtime Configuration Files, in particular the deps.json file that includes the dependencies for the application.

https://www.codeproject.com/Articles/1194332/Resolving-Assemblies-in-NET-Core

MyApp.deps.json file ([appname].deps.json) is designed to be processed by automated tools and should not be user-edited.

https://github.com/dotnet/cli/blob/master/Documentation/specs/runtime-configuration-file.md

Ну и всё равно это не то, что нужно. Потому что информацию о том, где продеплоена .dll-ка, которая является Sql-клиентом,
должен предоставлять компьютер, куда приложение деплоится. А не само это приложение, даже если потом можно будет переконфигурировать...

The exact mechanics of which version are selected are defined in the shared framework lookup document.

https://github.com/dotnet/core-setup/blob/master/Documentation/design-docs/multilevel-sharedfx-lookup.md

Ой, всё...