Summary of the new feature / enhancement

As a PowerShell user and Windows administrator, I would like PowerShell to support both its native $env:VARIABLE syntax and the traditional Windows Command Prompt %VARIABLE% syntax when referencing environment variables in commands and scripts.

For example, both of the following would resolve to the same environment variable value:

$env:USERPROFILE
%USERPROFILE%

Reason for the request:

Windows documentation, administrative utilities, installation instructions, and configuration interfaces frequently reference environment variables using the traditional %VARIABLE% notation.

For example, Windows Defender Firewall supports environment variables such as %windir% when specifying application paths in firewall rules.

However, when working in PowerShell, administrators must translate these references into PowerShell's $env:VARIABLE syntax or explicitly expand them using another method.

Supporting both syntaxes would:

• Improve consistency between PowerShell, Command Prompt, and Windows administrative interfaces.
• Make it easier to copy and adapt commands and paths from existing Windows documentation.
• Reduce the need to manually translate environment variable references.
• Improve usability for administrators and learners transitioning from Command Prompt to PowerShell.
• Allow existing Windows-style paths containing environment variables to be used more naturally in PowerShell commands and scripts.

The intent is not to replace PowerShell's existing environment variable syntax, but to provide additional compatibility and flexibility when working with Windows environment variables.

Proposed technical implementation details (optional)

Ideally, PowerShell would recognize and expand %VARIABLE% references in addition to its existing $env:VARIABLE syntax.

For example:

Current PowerShell behavior:

Write-Output $env:USERPROFILE
Get-Item "$env:WINDIR\System32"

Proposed additional syntax:

Write-Output %USERPROFILE%
Get-Item "%WINDIR%\System32"

Both forms should produce equivalent results.

This capability could also support variable expansion within strings:

$Path = "%ProgramData%\MyApplication\Logs"

PowerShell already provides similar functionality through .NET:

[Environment]::ExpandEnvironmentVariables(
    '%ProgramData%\MyApplication\Logs'
)

Additionally, PowerShell currently recognizes %VARIABLE% references when using the --% stop-parsing token with native Windows commands.

The proposed enhancement would make this functionality more accessible within normal PowerShell usage, without requiring explicit .NET method calls or the stop-parsing token.

Compatibility considerations:

I recognize that introducing additional variable expansion syntax could affect existing scripts that intentionally use literal percent-delimited strings.

Potential approaches could include:

• Providing the functionality through an opt-in experimental feature or preference setting to preserve backward compatibility.
• Following PowerShell's existing quoting conventions, where single-quoted strings remain literal.
• Clearly defining behavior when a referenced environment variable does not exist.
• Initially limiting the enhancement to Windows, where this notation is widely used.

The specific implementation should be determined by the PowerShell team, with an emphasis on maintaining backward compatibility while improving usability.

The primary objective is to allow administrators to use either environment variable notation naturally within PowerShell commands and scripts.