Related: #15239, #15250, #15276 - see overview in #15143.

Seemingly, with experimental feature PSNativeCommandArgumentPassing in effect (and preference variable $PSNativeCommandArgumentPassing set to 'Standard'), --%, the stop-parsing symbol is broken in that it is seemingly ignored: escaping of " chars. that follow is now unexpectedly being performed:

Steps to reproduce

[Update: The repro below no longer works, since find has since been put on the list of CLIs that implicitly trigger legacy argument-passing; however, the problem persists - see #18664]

On Windows (Unix is affected too, but --% doesn't make much sense there anyway):

# This worked up to preview 4.
'foo' | find --% /v "" | Should -Be 'foo'

Expected behavior

The test should succeed.

Actual behavior

The test fails, because the " chars. are \-escaped:

Access denied - \\
InvalidResult: Expected 'foo', but got $null.

In effect, command line find /v "\"\"" is passed behind the scenes - instead of find /v ""

Note that with without --% the command now works ('foo' | find /v "", which previously failed).

While that is great, --% must not be broken.

Environment data

PowerShell Core 7.2.0-preview.5