For example: Set-ExecutionPolicy. This command should simply not exist on Linux. Rather than throwing RuntimeErrorException terminating errors, I would prefer to get a command-not found, because that's something I can test for ahead of time.

Years of developing for moving targets on the web has taught us that the right way to avoid features that don't exist is to test for the feature, and not for the underlying OS, Architecture, or software version, because you never know when someone's going to finally figure out how to implement something.

If non-functioning commands are not hidden, there is no easy, fast way for scripts to test for whether commands will work -- you have to run them and catch the exception. However, many scripters will instead write incorrect conditional code based on the PSEdition (or operating system sniffing, but currently that's not even in $PSVersionTable #1997) which will prevent them from using the feature in the case where it's added later on.

In general, when a (core) module exposes a command (functioning or not), it's more difficult for another module to provide an implementation -- I know we can't anyway in this particular example, but that's the problem with picking examples ;-)

Suggestion: This should be exposed in the manifest.

I would like an easy way to identify commands that should be exported based on PSEdition, PSVersion, OS, or Architecture from the module manifest.

I don't want to have to wrap binary modules in script modules to put conditional Export-ModuleManifest statements in ... especially since putting the right values in the manifest for exported cmdlets is vital to discoverability.

One thought is to allow specific module manifests for platforms, like MyModule.Core-Linux.psd1 or something -- this would provide solutions to other design problems as well (like loading the right binary assemblies).