Allow "Invalid" keys in module manifests
Just ... STOP worrying about keys that you don't care about.
That way, 10 years from now, when all the old versions are gone, you'll finally be able to add keys to the manifest instead of stuffing more and more things into the module's PrivateData
We are investigating this, but please add votes & use cases that you feel are blocked by this problem to help us prioritize.
Kirk Munro commented
FYI to readers of this issue, if you're not sure what the issue is, do the following on a Windows 10 system:
PowerShell -version 2
The issue with that error is twofold:
1. It means that if a user tries to import any module that uses a "new" (not part of the current version of PowerShell you are in) manifest key, they get an unintuitive error, even if the module PSVersion clearly defines the minimum version that is required. e.g. If the module indicates PSVersion = 3.0, and if the manifest includes HelpInfoUri, and if you try to import that module on PSv2, rather than getting an error indicating that the module requires PowerShell 3.0 or later, users get a horrible error indicating that the manifest contains an invalid key. This is a horrible UX for end users who care nothing about the details of manifest keys.
2. It means that in broader scenarios where manifest keys would be useful for tools like PowerShellGet, like the PrivateData section that was added for publishing to a PowerShell Gallery, those keys must go in PrivateData in order for downlevel support to be added because downlevel versions of PowerShell will always throw the error like you see above as long as the current logic remains as it is. Instead, PowerShell could simply ignore the keys that it does not recognize, trusting the module author that they are there for a reason.
Downlevel support is really important, and the current approach (PrivateData) feels more like a hack than a solution. This change should have been done in PowerShell 3.0. Please vote this up.