.NET Core 2 introduced the concept of the AssemblyLoadContext.

This offers the possibility of preventing assembly dependency conflicts between modules, and even the possibility of unloading assemblies.

This has been successfully implemented in at least one PowerShell module in the wild. There's a blog post detailing how to do this here.

However, the question remains as to whether PowerShell should attempt to provide this functionality itself.

While it may sound like it definitely should, there are a number of subtle considerations, and it may be that PowerShell won't be able to get them right for all modules, making module loading more complex and error prone.

Some things to consider:

• Should PowerShell users be able to choose whether a module is loaded through an ALC?
• Should module authors be able to choose the same?
• Loading through an ALC can create type identity issues if a module exposes its identities' types in its own API. This is a legitimate thing to do (e.g. a YAML-handling module that emits YAML objects defined by its underlying library). How do we handle this? Are we responsible for detecting it ahead of time? (In many cases this will be impossible, since the exposed APIs on an object in PowerShell are determined by reflection at runtime)
• Passing dependency-typed objects between commands from different modules is also a valid scenario. Is there special handling here?
• Is it feasible (both technically and in terms of maintenance) to provide tooling to help module authors analyse and understand how assembly load contexts should work with their module?
• Will using ALCs for modules affect PowerShell classes in terms of how they are currently implemented or how they should work?

Note: An RFC about this topic that was withdrawn can be found here: https://github.com/PowerShell/PowerShell-RFC/blob/master/X-Withdrawn/RFC0043-Loading-Module-Into-Isolated-AssemblyLoadContext.md
The biggest challenge is the type identity issue. The module dependency is another challenge -- how to handle a required module? Today, the required module is loaded once and shared by multiple modules that depend on it.

Some other places where ALCs have been discussed:

• Unable to load multiple versions of .Net assembly module dependencies. #2083
• Is there a way to avert the diamond dependency problem for modules that use .Net types? #5504
• Powershell 7.x : Cannot use type from dll (built for netstandard2.0) #12052
• Workarounds in loading assembly with different versions #11571
• Do not resolve types from assemblies that are loaded in separate AssemblyLoadContext #11088
• Add-Type : Could not load file or assembly netstandard #10955