A common issue when developing modules is running into assembly conflicts with other modules due to strong-named assemblies and having to use a Powershell-Level "binding redirect" by intercepting the assembly loader for Powershell 5.1.
Powershell 7 does a sort of auto-binding redirection as long as the highest version dll is loaded first, and has support for assemblyloadcontext which if implemented properly can "hide" the conflicting DLLs from each other, which helps mitigate the issues. However, 5.1 compatibility is still important for several years due to its "in-box" status.
This will only become more common, especially as modules like PSGetv3 and other modules effectively become de-facto and specify their own version of common items like Newtonsoft.Json, Yaml, Microsoft.Extensions.Configuration, and Microsoft.Extensions.Logging
As such, at least for 5.1 compatibility, Powershell Standard should include an optional baseline version reference to these assemblies so that modules can be using the same and have a reasonable expectation not to conflict with each other. For instance, Microsoft.Extensions.Configuration should target the 3.1 version line and NewtonSoft.Json should target the 11.x line.
A module can still opt to go for a newer assembly, with the expectation that it may conflict in 5.1 but probably be fine in 7 as long as it is loaded first.
A common issue when developing modules is running into assembly conflicts with other modules due to strong-named assemblies and having to use a Powershell-Level "binding redirect" by intercepting the assembly loader for Powershell 5.1.
Powershell 7 does a sort of auto-binding redirection as long as the highest version dll is loaded first, and has support for assemblyloadcontext which if implemented properly can "hide" the conflicting DLLs from each other, which helps mitigate the issues. However, 5.1 compatibility is still important for several years due to its "in-box" status.
This will only become more common, especially as modules like PSGetv3 and other modules effectively become de-facto and specify their own version of common items like Newtonsoft.Json, Yaml, Microsoft.Extensions.Configuration, and Microsoft.Extensions.Logging
As such, at least for 5.1 compatibility, Powershell Standard should include an optional baseline version reference to these assemblies so that modules can be using the same and have a reasonable expectation not to conflict with each other. For instance, Microsoft.Extensions.Configuration should target the 3.1 version line and NewtonSoft.Json should target the 11.x line.
A module can still opt to go for a newer assembly, with the expectation that it may conflict in 5.1 but probably be fine in 7 as long as it is loaded first.