Parsing of "-"-prefixed barewords in argument mode is broken #4578

Note:

• As demonstrated in Parameter values disambiguated with their explicit parameter names should not require quoting #4576 (comment), --prefixed barewords are currently only accepted if they happen not to match the name or name prefix of a parameter supported by the command - an inconsistency that is problematic in itself.

• Mark Kraus (@markekraus)'s suggestion is to disallow --prefixed barewords altogether - to always require quoting of values starting with -, which would make this issue moot - see Parameter values disambiguated with their explicit parameter names should not require quoting #4576 (comment)

• I personally think that there's no good reason to disallow them, and that it is sufficient to let the target command's specific syntax disambiguate between values and parameters, not least for consistency with the CLI - see Parameter values disambiguated with their explicit parameter names should not require quoting #4576 (comment)

If --prefixed barewords continue to be supported (in principle, bugs notwithstanding), their parsing currently differs from non---prefixed barewords in significant and unexpected ways:

Steps to reproduce

Write-Output -InputObject a
Write-Output -InputObject -a
Write-Output -InputObject -a.ps1
Write-Output -InputObject -a$HOME
Write-Output -InputObject a$HOME

Expected behavior

a
-a
-a.ps1
-a/home/jdoe
a/home/jdoe

Actual behavior

a
-a
# ERROR: '.ps1' was interpreted as a *separate argument*
Write-Output : A positional parameter cannot be found that accepts argument '.ps1'.   
-a$HOME   # NOT EXPANDED
a/home/jdoe

Environment data

PowerShell Core v6.0.0-beta.5 on macOS 10.12.6
PowerShell Core v6.0.0-beta.5 on Ubuntu 16.04.3 LTS
PowerShell Core v6.0.0-beta.5 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.483 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)