Note: This seems to affect all file-creating cmdlets - including > and >> - with the laudable exception of Set-Content and Add-Content.

Conceptually related: #7999

Say you want to create a file literally named file[1].txt.

In order to successfully pass this name to a -Path parameter (or -FilePath for -OutFile), it must be escaped as file`[1`].txt, because -Path parameters interpret their arguments as wildcard expressions.

While such an escaped path is accepted, the problem is that it isn't retranslated into its literal equivalent on file creation, resulting in the escaped representation being used as the filename; in the example above, you end up with a file literally named file`[1`].txt instead of the intended file[1].txt

This problem can generally be avoided by passing the filename to the -LiteralPath parameter instead, but that is not yet always an option - see #3174 - and, of course, the bug is worth fixing either way.

Steps to reproduce

Run the following Pester tests:

Describe '-Path file-creation test' {
  BeforeAll { Push-Location TestDrive:\ }
  AfterAll { Pop-Location }
  It "Escaped wildcard paths are created as their literal equivalents" {
   'hi' | Out-File -FilePath 'file`[1`].txt'
    Test-Path -LiteralPath 'file[1].txt' | Should -Be $true
    Test-Path -LiteralPath 'file`[1`].txt' | Should -Be $false
 }
}

Expected behavior

The tests should pass.

Actual behavior

The tests fail, because the actual name of the file created is literally file`[1`].txt, i.e., the escaped name.

Environment data

PowerShell Core 6.2.0 / Windows PowerShell v5.1