> We already update the current shell, so if you start a new 
> terminal/Powershell/cmd/etc. instance it should have the 
> updated variable. 

The installer broadcasts an "Environment" message to top-level windows. In practice, only Explorer listens for and reloads its environment for this window message. For most programs, a new instance has to be run from Explorer in order to get the updated environment. 

CMD and PowerShell don't own any windows, so they cannot get this message in principle. The console-session host process (conhost or openconsole) may own a top-level window if it wasn't allocated with CREATE_NO_WINDOW and wasn't created as a ConPTY server (e.g. under Windows Terminal). But the console doesn't have a console control event for this case (e.g. something like a hypothetical CTRL_ENVIRONMENT_EVENT) that it sends to client processes. It's assumed that console applications that need to interact with the desktop environment will create at least a hidden window.

Without the "Environment" message, it's still possible for the user to run a script that reloads the environment in place in CMD or PowerShell. The environment has to be loaded in four passes: system REG_SZ values, system REG_EXPAND_SZ values, user REG_SZ values, and user REG_EXPAND_SZ values. User values should always be able to depend on system values, and REG_EXPAND_SZ values should always be able to depend on REG_SZ values. This is the way WinAPI CreateEnvironmentBlock has always worked. When reloading PATH, this is an issue if a new machine PATH value depends on new/modified REG_SZ system variables or if a new user PATH value depends on new/modified system variables or new/modified REG_SZ user variables.