Note: In addition to the immediate bug, the current behavior of selecting the explicitly defined parameter set with its mandatory parameter in parameter-less invocations is questionable as a whole - see the proposal below.

Steps to reproduce

function foo {
  [CmdletBinding()]   # No default parameter set.
  param(

    # Only one explicitly defined parameter set, comprising
    # one mandatory and one optional parameter.
    [Parameter(ParameterSetName='bar', Mandatory)]
    $MandatoryInItsSetButOptionalOverall,
    [Parameter(ParameterSetName='bar')]
    $MustBeCombinedWithMandatory,

    # An untagged (all-parameter-sets) parameter.
    $UnrelatedAndOptional
  )
  # Echo the effective parameter set.
  $PSCmdlet.ParameterSetName
}

# Note: This will (questionably) prompt for a -MandatoryInItsSetButOptionalOverall value.
#       Submit any value or just press Enter.
foo | Should -Be 'bar'

Expected behavior

The test should succeed.

Actual behavior

The test fails:

Expected strings to be the same, but they were different. 
Expected length: 3 Actual length:   18 Strings differ at index 0. 
Expected: 'bar' But was: '__AllParameterSets'

That is, even though set bar was clearly selected - otherwise there would have been no prompt - __AllParameterSets was then reported as the effective parameter set.

As an aside regarding the fundamental behavior:

As the naming of the parameters suggests, bar shouldn't have become the effective parameter set by default.
While that can be worked around by naming an (otherwise unused) different default parameter set in the [CmdletBinding()] attribute, doing so shouldn't be necessary - see the initial post of #11143 for an example, and the proposal below for a potential resolution.

Environment data

PowerShell Core 7.0.0-preview.6