^{Related: #6292 and #6360}

Note that . should receive no special treatment in tokens such as -foo=bar.baz, because the token is unquoted and does not start with a special char. ($ @ ( ' " ) and should therefore result in interpretation as an (expandable) string, according to about_Parsing.

In reality, though, the unexpected special treatment stems from - being the 1st character, which causes interpretation as a parameter name, even though that doesn't apply in this case.

Steps to reproduce

# Helper function that echoes all arguments.
function Out-Argument { $i = 0; $Args | % { 'arg[{0}]: {1}' -f $i++, $_ } }

# Pass an unquoted argument that starts with "-" and has an embedded "." (outside of "..." or '...')
Out-Argument -foo=bar.baz

Expected behavior

arg[0]: -foo=bar.baz

Actual behavior

arg[0]: -foo=bar
arg[1]: .baz

The token was unexpectedly broken in two. Note that this equally applies when calling external utilities.

And it is indeed in the context of calling external programs that an argument with such (non-PowerShell) syntax (-<param-name>=<value>) may need to be passed - see this SO question and this one.

(PSv2 exhibited a variation of the bug - see this SO question.)

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)

Workarounds

# "`"-escape the leading "-"
Out-Argument `-foo=bar.baz

# Quote the whole argument
Out-Argument '-foo=bar.baz'