In order to support cross-platform modules, we need to support dependent assembly packages properly, the way that dotnet build does -- we need to be able to either:

1. make requiredAssemblies like package.json: a list of nuget packages you can load from the .nuget folder (the new compile-time GAC)
2. ship .nupkg files, and refer to the assemblies in requiredAssemblies
3. include the lib/ folder from the nupkg files, and have you PowerShell pick the right one based on platform.

To me, it's perfectly obvious that a single machine-wide .nuget folder -- which PowerShell could un-pack from on demand -- would be the ideal solution, requiring the least amount of disk space and work on the part of developers. It would require the NuGet package provider for PowerShell PackageManagement be updated, and significant changes to the core to do the work of unpacking and loading the right assemblies...

Short of that, a .nuget folder (or "assemblies" or whatever) in my PowerShell folder would be a good fall-back option. Same basic story.

Failing that, the fallback option would be to allow module authors to include the actual nupkg files in their modules. It requires almost all of the same development, and you end up with a lot more copies of the assemblies, but since it doesn't require a working PackageManagement provider (at least, not at runtime), it's somewhat simpler, and self-contained.

As a final, worst-case scenario, we could require module authors to actually unpack the nupkg files. That is, we could require each module author to Install-Package Dependency -Destination MyModuleFolder and put the lib folder from the nuget packages directly within their module. This way PowerShell is only responsible to load the right assembly based on the platform, but we still get cross-platform modules.

Backwards compatibility

Note that for the sake of making modules compatible with PowerShell 5.x and lower, all of these methods require cutting off support at PowerShell 3 (.Net 4) and shipping the .Net 4 assemblies loose in the root folder of the module. As long as the manifest just says: RequiredAssemblies = "Whatever.dll", legacy Windows PowerShell only looks in the GAC or in the module folder.