@ili101 discovered that binding a parameter via the pipeline can cause PowerShell to select the wrong parameter set under certain circumstances.

The issue can be resolved by designating a default parameter set.

Arguably, PowerShell shouldn't pick a default parameter set at all in this case, but it does:

• defensibly with direct arguments,
• seemingly incorrectly with conceptually equivalent pipeline input

Note that it is legitimate use case to have an explicit parameter set that has no mandatory parameter (set A below): You may want to group multiple parameters as logically related, even if none of them is individually mandatory.

Steps to reproduce

function foo
{
  [CmdletBinding()] # DefaultParameterSetName='A' would make the issue go away
  Param(
    [Parameter(ParameterSetName = 'A')]            $A1,
    [Parameter(ParameterSetName = 'A')]            $A2,
    [Parameter(ParameterSetName = 'B', Mandatory)] $B1,
    [Parameter(ParameterSetName = 'B')]            $B2,
    [Parameter(ValueFromPipeline)]                 $InputObject
  )
  $PSCmdlet.ParameterSetName
}

# OK: Argument-less invocation selects 'A'
foo  | Should -Be A
# OK: Binding -InputObject by direct argument also selects 'A' 
foo -InputObject 1 | Should -Be A
# FAILS: Binding -InputObject via the pipeline inexplicably selects 'B'
# Just press Enter to answer the prompt.
& { 1 | foo }      | Should -Be A

Expected behavior

All tests should pass.

Actual behavior

The 3rd test fails: It unexpectedly selects set B prompts for a value for -B1.

Expected strings to be the same, but they were different. 
String lengths are both 1. Strings differ at index 0. 
Expected: 'A' But was:  'B'

Environment data

PowerShell Core 7.0.0-preview.6