It is not going to be uncommon for module authors to want to provide slightly different functionality on different operating systems e.g. the module provides 30 commands, two of which only work on Windows PowerShell. Right now, there is no good way to declare "conditional" module exports in the manifest where the condition is the OS platform.

In fact, even PowerShellVersion is problematic if you design your module to load into both Windows PowerShell and PowerShell Core. Which PowerShell version does that refer to? Windows PowerShell? PowerShell Core? What if at some point, on PS Core I require 6.1.0? Does that mean my module can't load into Windows PowerShell 5.x anymore - probably. But I may not be providing that functionality when I'm loaded into Windows PowerShell (runtime decision) so Win PS 5.1 should be allowed when loading into Windows PowerShell.

AFAICT all of these field's values may be conditional upon the OS platform and/or the PowerShell platform (Win or Core)

• PowerShellVersion
• PowerShellHostName / Version
• RequiredAssemblies
• RequiredModules
• ModuleList
• NestedModules
• FormatsToProcess
• ScriptsToProcess
• TypesToProcess
• ClrVersion
• DotNetFrameworkVersion
• AliasesToExport although CompatiblePSEditions might mitigate this one
• CmdletsToExport
• FunctionsToExport
• VariablesToExport
• Tags

In order to make any changes backwards compatible with existing Windows PowerShell instance, we could put all the conditional declarations in PrivateData. This implies that fields not in PrivateData inherently apply to Windows PowerShell when module is loaded by Windows PowerShell. PowerShell Core could be modified to process the conditional fields in PrivateData. What might those look like? Maybe this?

    PrivateData = @{
        PSManifestEx = @{
            PowerShellVersion = "6.1.0" # fields at this level apply to all OS platforms for PS Core
            Linux = @{
                RequiredModules = @(...)
                CmdletsToExport = @(...)
            }
            MacOS = @{
                RequiredModules = @(...)
                CmdletsToExport = @(...)
            }
            Windows = @{ # this is for PowerShell Core on Windows
                RequiredModules = @(...)
                CmdletsToExport = @(...)
            }
        }

This doesn't take into account Nano server which I don't have enough experience with to take it into account. Anyway, this is just something to get the conversation started.

Long term, this approach seems less than ideal - burying so much important metadata under PrivateData.