Powershell setting EnvironmentVariable works in ISE but not Console - powershell

Question

I have an odd Powershell behavior i wish to understand.
If i set a permanent Environment Variable and start a process like the following
[Environment]::SetEnvironmentVariable('FOO','BAR','User')
Start-Process notepad
This works as expected in ISE Editor and if i type it after one other in the Console. However if i run it as a .\script.ps1 Script from the Console the Start-Process will ignore the new or the changed Environment Variable. Even the Environment Variable is properly set before Start-Process is executed. I tested this by adding Sleep and checking the Environment Variable Dialogue manually. If the script is run a second time the Process will read the Environment Variable as expected since it has been changed before already.
Why is the Console behavior not the same as in ISE in this case?
I already tried if this has to do with specific Assemblies that are loaded in ISE and not the Console but it does not seam so.
I also tried to run as STA but it did not work either.

Answer 1

Note: This answer is specific to Windows, because System.Environment.SetEnvironmentVariable only supports modifying persistent environment-variable definitions (via target scopes User and Machine) there. The fundamentals of how PowerShell determines a child process' environment apply on Unix-like platforms too, however.
[Environment]::SetEnvironmentVariable() with a target-scope System.EnvironmentVariableTarget argument of User or Machine only updates the persistent environment-variable definitions in the registry - it doesn't also update the current process's in-memory variables.
By contrast, target Process updates only the current process' variables non-persistently.
As such, [Environment]::SetEnvironmentVariable('FOO','BAR','Process') is the equivalent of $env:FOO = 'BAR'
Start-Process by default uses the current process's environment variables[1] and therefore doesn't see variables (yet) that were created or updated by targeting the User or Machine scopes in the same process.[2]
Start-Process's -UseNewEnvironment parameter is in principle designed to do what you want: it is meant to start the new process with environment-variable values read from the registry, ignoring the calling process' values - however, this feature is broken as of PowerShell [Core] v7.0 - see this GitHub issue.
The workaround is to also define the new variable in the current process:
# Update both the registry and the current process.
foreach ($targetScope in 'User', 'Process') {
[Environment]::SetEnvironmentVariable('FOO', 'BAR', $targetScope)
}
# Start a new process with the new value in effect.
Start-Process -NoNewWindow -Wait powershell '-c \"`$env:FOO is: $env:FOO\"'
Note that - unlike what -UseNewEnvironment should do - this makes the new process inherit all process-only (in-memory) environment variables / values too.
[1] A process is given a block of environment variables on startup, often a copy of the parent process's block (as PowerShell itself does by default when creating child processes). That startup block may or may not reflect the then-current registry definitions. In-process modifications of the environment block are lost when the process terminates, unless they are explicitly persisted, such as with [Environment]::SetEnvironmentVariable() and target scopes User or Machine. As all programs that modify the persistently defined environment variables should do, [Environment]::SetEnvironmentVariable() broadcasts Windows message WM_SETTINGCHANGE as a notification of the change, but few programs are designed to listen to it and therefore few update their in-process environment variables in response (which isn't appropriate for all programs).
[2] However, if you start the new process as an administrator with -Verb RunAs (Windows-only) using the current user's credentials, the new process will see the new/updated definitions, because it then does not use the current process' environment variables and instead reads the then-current definitions from the registry.