GeezerVison

1. We should replace the alias with cmdlet and above too.
2. I'd expect that users will type the path without escape - it doesn't work.
3. I'd expect that it will work for literal path too - it doesn't work. It could be out of the PR but I'd prefer to remove the fix from the PR and get a full fix in another PR for all scenarios. We should do full review how we process all special chars in Path and in LiteralPath. I do not see the point in partial fixes because they can break something without having a full set of tests.

1. Updated test.
2. I disagree. User should type escape for -Path (which support globbing), just like we do in bash (eg. touch \[test\]). But if you typed escape and auto completion still did not work, that is because by default, powershell treats "unquoted string without space" like "double-quoted string", that "double-quoted string" will consume escape character. For file name [test], either Get-Content -Path ```[ or Get-Content -Path '`[ will work.
3. Would you please let me know what did not work for -LiteraPath?
   I tried Get-Item -LiteralPath [(TAB) for a file named [test] and it did auto complete.

2. Consider interactive UX. User do dir and then type directory or file name as one see on screen - without escapes. In the scenario both the user and PowerShell know right name. And more, we can have both names - with escape char too.
3. Get-Item '.\My `[

2. The problem is, -Path support wildcard. When a path can be an expression, the special characters should always be escaped otherwise it will become too complicated. For example, in a directory there are A.txt, B.txt and [AB].txt, what should Get-Item -Path [AB].txt return?
3. I tested both -Path and -LiteralPath and both will complete the file name. eg.
   New-Item -Name 'My [test]'
Get-Item '.\My `[ will be completed to Get-Item '.\My `[test`]', and
   Get-Item -LiteralPath '.\My [ will be completed to Get-Item -LiteralPath '.\My [test]'
   Did you use the build here? https://ci.appveyor.com/project/PowerShell/powershell/build/v6.1.0-rc.10960/job/3i76g2ar1wqlvw7x/artifacts

Why we always should escape the escape char? What scenario don't work without fix?

1. When we accidentally created a file named `[test`]2 due to the incorrect handling of wildcard character, we cannot remove it using the -Path parameter with the tab completed name.
2. When I escaped string A and get B, and try to unescape B, I would expected that A will be returned, but it is not when A contains escape character.
3. The wildcard pattern parser always treat escape character as escape character.

My understanding is that we should test if a file/directory/path exists before trying escape. If exist then return the path. Then continue with escaping wildcard chars. Then continue with expansion wildcards if -Path.
Also what if there is some special symbols in the path? Seems we should process them in cycle.

Okay, I know what is wrong here. This part is to fix the WildcardPattern::Escape function itself, which is not necessary related to the file system.
When WildcardPattern::Get parse a pattern string, it always treats the escape character as escape character of an escape character. That means, `` will be parsed to `.
And so is the WildcardPattern::Unescape method, [WildcardPattern]::Unescape('``') will return ` instead of ``.
But, [WildcardPattern]::Escape('`') does not escape the escape character, which conflicts with the others.

kwkam I see your point.
We have the public API

public static string Escape(string pattern)

So the change is a breaking change and it is not desirable to change this behavior until it is established that this is a significant bug.

Ilya (@iSazonov) Yes, we should be careful with changes in public API, but I doubt if this is not a significant bug. For example, there is a list of text:

`[HIGH] patch 1`
`[MED] update 1`
`[LOW] patch 1`
`[MED] patch 2`
`[HIGH] hotfix 3`
`[LOW] patch 2`
`[LOW] hotfix 3`

Now, I want to search for `[LOW] patch 1` and `[LOW] patch 2`, and I am using WildcardPattern:

$prefix = '`[LOW] patch '
$pattern = '[1-2]'
$suffix = '`'
$sarg = [WildcardPattern]::Escape($prefix) + $pattern + [WildcardPattern]::Escape($suffix)
$opts = [Management.Automation.WildcardOptions]::Compiled
$matcher = [WildcardPattern]::Get($sarg, $opts)
$ListOfText | ? {$matcher.IsMatch($_)}

No result will be return because of the inconsistency between the Escape method and the WildcardPattern parser. (And this is also the cause of the issue in auto-completed filename which contains escape character)

Thanks for good example!

We need PowerShell Committee conclusion.
/cc Steve Lee (@SteveL-MSFT)

should all changes be behind the experimental feature?

This was a condition of the committee

Except filename completion will now also escape * and ? in non-literal path, the behaviour should be identical unless the experimental feature (the breaking part) is enabled.