This will break if the target remote session is an older version and does not support the new common parameters. We will need to update PowerShell remote encoding to support this only for target versions that implement the new common parameters. See:

Thanks @PaulHigin, I'll look into this.

I would also appreciate your thoughts on this comment from earlier, because taking that approach should allow us to deprecate -Verbose and -Debug (which will have questionable usefulness going forward with this change), while bringing their muscle memory and aliases forward, without breaking backwards compatibility, and it would be nice if we could replace -Verbose and -Debug to reduce unnecessary common parameters. That work could also be done independently, of course, but it is worth thinking about as part of this PR.

I don't fully understand the comment. Can you provide an example? But it sounds like a separate issue that should be discussed apart from these changes.

It's really quite simple. Consider something you might do today, such as this:

Import-Module Microsoft.Graph -Verbose

That gives you verbose output that is generated during module import.

Once this PR is finalized/merged, you could do the same like this:

Import-Module -VerboseAction Continue

But the original syntax would work as well.

Where the question comes into play is this: do we need both -Verbose and -VerboseAction, or -Debug and -DebugAction?

The latter is necessary to allow you to properly handle those streams like any other stream. The former is "necessary" for backwards compatibility and muscle memory. My point was that it is possible to support both of these with a single parameter, which would treat a switch-like invocation as if you invoked the corresponding -*Action parameter with Continue.

i.e. Import-Module Microsoft.Graph -Verbose would be the exact same as invoking Import-Module Microsoft.Graph -VerboseAction Continue, by simply making the -VerboseAction parameter "switchable" (the generic type I said could be written). This approach would allow the -Verbose and -Debug parameters to be gracefully deprecated as superceded by -VerboseAction and -DebugAction, respectively.

Another data point that could influence this: using -Verbose and -Debug is functionally different (in a bad way) than using a typical -*Action parameter. Why? Because of their implementation.

For example, this shows verbose output from Import-Module, which is expected:

Remove-Module MicrosoftTeams
# Turn off verbose messages by default
$VerbosePreference = [System.Management.Automation.ActionPreference]::SilentlyContinue
& {
    [CmdletBinding()]
    param()
    Write-Verbose 'Am I showing verbose output?'
    Import-Module MicrosoftTeams
} -Verbose

Unfortunately, so does this, which is unexpected:

Remove-Module MicrosoftTeams
# Turn on verbose messages by default
$VerbosePreference = [System.Management.Automation.ActionPreference]::Continue
& {
    [CmdletBinding()]
    param()
    Write-Verbose 'Am I showing verbose output?'
    Import-Module MicrosoftTeams
} -Verbose:$false

Why would Write-Verbose be influenced by the -Verbose common parameter in the calling scope, but not Import-Module? Maybe there is something else going on here, but I believe that this would be corrected by deprecating -Verbose and -Debug without breaking existing functionality by defining them such that they work as shorthand for -VerboseAction Continue and -DebugAction Continue, as described above.