Summary of the new feature/enhancement

As a module author,
I want the CompatiblePSEditions tag in module manifests to work if it is defined in the PrivateData.PSData section of a module manifest
so that I can properly indicate which editions of PowerShell are supported in a module that supports current versions of PowerShell as well as downlevel versions below PowerShell 5.1.

Justification

There are modules shared in the Gallery that appear to only support Windows PowerShell, even if they actually support cross platform PowerShell. Why? Because authors of modules that support versions of Windows PowerShell lower than 5.1 cannot add the CompatiblePSEditions tag to the top level of their manifest because doing so will prevent those modules from loading on downlevel versions of PowerShell.

Looking at modules in the Gallery, if you try to identify which modules support cross platform PowerShell, you cannot. You can identify some modules that support cross platform PowerShell by checking the Linux or macOS checkboxes in the filter panel on the left-hand side of search results, however doing so will automatically filter out all modules that do not have a CompatiblePSEditions tag in their manifest, even if they support Linux and/or macOS.

For example, look for a Teams module in the Gallery that runs on Linux (PowerShell Core or PowerShell 7+). If you search for "Teams", you'll see a few modules. If you then filter for Linux support, you'll only see one module: PSTeams. That was written by a community member. The "MicrosoftTeams" module is the official module, and it works cross platform, but it gets hidden from the results because that module does not define CompatiblePSEditions in its manifest since it supports PowerShell 3 or later.

This is a rampant problem for modules in the Gallery that needs to be addressed if we want to increase adoption of PowerShell 7 once it is released.

Proposed technical implementation details

The only way to resolve this problem is to support CompatiblePSEditions in PrivateData.PSData in a module manifest, by doing the following:

1. Update New-ModuleManifest such that it can be used to generate a manifest with the CompatiblePSEditions information stored in PrivateData.PSData. Module authors can also define it at the top level since it is a supported tag in manifests in PowerShell 5.1 and later; however, doing so breaks backward compatibility, which may be undesirable. If both PrivateData.PSData.CompatiblePSEditions and CompatiblePSEditions are defined in a manifest, an error should be generated on module load if the values are different.

2. Update the PowerShell Gallery so that it recognizes PrivateData.PSData.CompatiblePSEditions as a source of compatible edition information, and use that when storing the metadata about the module.

3. Update the PowerShell Gallery so that it shows the supported editions in the PowerShell Gallery UI with the other module details, close enough to the top that users clearly see what versions of PowerShell are supported even if they don't filter for specific OS support.

4. Update Find-Module in PowerShellGet such that it surfaces this information in the results it returns, and add a parameter to filter on specific OSes that should be supported, defaulting to the current operating system.