Parameter parsing/passing: in native executable calls, arguments that look like named PowerShell arguments do not treat the grouping operator as a separate argument

Follow-up from https://github.com/PowerShell/PowerShell/issues/1995#issuecomment-676617510. Related: #13489, #6360, #6291

In short: Using an expression (via (...), the grouping operator) as part of an argument normally causes the output from that expression to be passed as a separate argument (which in itself may be surprising - see #6467).

This is not the case in the following, very specific scenario:

• An external (native) executable is being called.

• The start of the argument looks something like -foo:, i.e. looks like a named PowerShell argument, though that concept doesn’t apply when calling external programs; note that any other prefix before the (...) does not trigger the symptom.

In that event, the (stringified) (...) output is directly attached to -foo: to form a single argument, though note that if the output is a collection, only the first element is attached.

There is no good reason for this anomaly, and the behavior with collections is virtually useless.

Steps to reproduce

# OK: PowerShell command: the output from (...) is passed as a *separate* argument.
Write-Output -foo:('bar', 'baz') | Should -BeExactly '-foo:', ('bar', 'baz')

# On Unix:
# BROKEN: External program: the output from (...) is partially passed as part of `-foo:`, namely 
# (only) the *first* array element.
printf '%s\n' -foo:('bar', 'baz') | Should -Be '-foo:', 'bar', 'baz'

Expected behavior

The tests should pass.

Actual behavior

The second test fails:

Expected @('-foo:', 'bar', 'baz'), but got @('-foo:bar', 'baz')

Note how only 2 arguments were passed, because the first array element, bar, was directly attached to -foo:.

Environment data

PowerShell Core 7.1.0-preview.6

[vexx32]

/cc @JamesWTruher for visibility.

@mklement0 I half suspect you must spend a lot of time trying to break things around this 😂 (But honestly, thanks; I doubt we’d find half these things if you didn’t!)

[mklement0]

Actually, the call PWSH A.PS1 -A:1,2 works as well.

No, that passes'1,2' as single string (i.e, neither string '1 2' nor array 1, 2).

I deny any wrongdoing with the syntax -A:$A

This is another manifestation of #13489 - it should be treated the same as "-A:$A" and therefore pass a single argument with verbatim content -A:1 2, but it currently behaves the same (broken) way as -A:(1,2).