^{Related: #6291, #6292, and #4624}

Following up from #6292 (comment):

Note: The tokens in question, such as -foo:bar, look like named PowerShell arguments (and, behind the scenes, are initially always parsed as such - see @BrucePay's comment below), but should be passed through as-is (except for possibly expanding the string) when calling external programs.

Tokens that happen to look like -foo.bar suffer a similar fate (see #6291).

This already works as expected with direct argument passing (e.g.,
echoArgs -foo:bar passes -foo:bar as a single argument
), but not when passing $Args / splatting it (@Args).

Note: The problem is fundamental to the use of $Args / @Args and, while perhaps less common, also affects its use when calling PowerShell-native commands - see comment below.

Steps to reproduce

Run on macOS or Linux.

function baz {
  bash -c 'for a; do echo $a; done' - $Args   # note: same with @Args
}

baz -foo:bar
'---'
baz -foo.bar

Expected behavior

-foo:bar
---
-foo.bar

Actual behavior

-foo:
bar
---
-foo
.bar

The arguments are unexpectedly broken in two. See linked comment for background.

Environment data

PowerShell Core v6.0.1 on macOS 10.13.3
PowerShell Core v6.0.1 on Ubuntu 16.04.3 LTS
PowerShell Core v6.0.1 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.674 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)