Unless you use -LiteralPath, square brackets cause real problems with character escaping. The problem comes from PowerShell de-escaping the strings multiple times internally and using special characters for pattern matching. Getting PowerShell to correctly recognize a literal square bracket in a path string is complex.
If you're using single-quote strings, a bracket needs two backticks to escape it. If you're using double-quote strings, a bracket needs four backticks to escape it.
If you're looking for a file named MyFile[1].txt, you need to use either:
'MyFile``[1``].txt'
or:
"MyFile````[1````].txt"
Yes, it's a pain. To see why it does this, you have to know what's going on. It's easy to do that by working backwards.
Let's say you want to get a file literally named [ab].txt.
The wildcard pattern matching that Get-ChildItem does means that if it gets [ab].txt as the path, then it will look for files named a.txt and b.txt. So, if we want to match a literal [ab].txt, we have to escape our brackets with the escape character: the backtick. That gives us this as the actual string of characters we want Get-ChildItem to use for the filespec:
`[ab`].txt
However, we have to pass this filespec as a string. That means Get-ChildItem will escape those backticks, but that's not what we want! We want literal backticks. So, we escape the backticks with backticks in our string to make sure Get-ChildItem uses the right filespec:
'``[ab``].txt'
If we want to use double-quoted strings, then we have to escape each backtick again, as the double-quoted string will de-escape the string. And that's how you end up with this:
"````[ab````].txt"
This is why so many PowerShell functions that take filespecs have the -LiteralPath option.
