This is how PowerShell Variables are designed to work. Variables your scripts or functions set only last as long as they're running, when they end, their values go away.

In what you're doing today, you're changing the $global scope variable but not running a script or function. You're effectively in the global scope already.

In order to use those nested scopes, you need to run a script or function, like this script below, called scratch.ps1

#script inherited the previous value

"script: current favorite animal is $MyFavoriteAnimal, inherited"

#now setting a script level variable, which lasts till the script ends
$MyFavoriteAnimal = "fox"

"script: current favorite animal is $MyFavoriteAnimal"

function GetAnimal(){
   #this function will inherit the variable value already set in the script scope
   "function: my favorite animal is currently $MyFavoriteAnimal"

   #now the function sets its own value for this variable, in the function scope
   $MyFavoriteAnimal = "dog"

   #the value remains changed until the function ends
   "function: my favorite animal is currently $MyFavoriteAnimal"
}

getAnimal

#the function will have ended, so now the script scope value is 'back'
"script: My favorite animal is now $MyFavoriteAnimal"

To access this functionality, you'll need to use scripts or functions.

You can use the Set-Variable cmdlet. Passing $global:var3 sends the value of $var3, which is not what you want. You want to send the name.

$global:var1 = $null

function foo (b, $varName)
{
   Set-Variable -Name $varName -Value (b) -Scope Global
}

foo 1 2 var1

This is not very good programming practice, though. Below would be much more straightforward, and less likely to introduce bugs later:

$global:var1 = $null

function ComputeNewValue (b)
{
   b
}

$global:var1 = ComputeNewValue 1 2

From https://technet.microsoft.com/en-us/library/hh847849.aspx

An item that you created within a scope can be changed only in the scope in which it was created, unless you explicitly specify a different scope.

so you could use $Global:x = ... to set it.

Powershell scripts are often copied and pasted in blocks to implement functionality, and often methods are written to be used by multiple scripts. By restricting assignment to the defining scope for a variable, you ensure that even if two pasted blocks of code use the same variable name, they cannot improperly change data that the other block depends on, without explicitly stating that they wish to do so. This helps to make blocks more modular, and helps to identify unintentional name collisions.

Edit:

a note on powershell scope: Powershell cascades scopes, so the local scope always contains objects defined in ancestor scopes (parent, grantparent, global, etc). That means that a variable defined globally or in a parent stack frame (a function calling a function) are always accessible, whereas objects defined in child scopes are not. In this case, the only restriction is that a child scope cannot modify a parent scopes value, unless that scope is defined explicitly.

From: https://technet.microsoft.com/en-us/library/hh847849.aspx

The following are the basic rules of scope:

    - An item you include in a scope is visible in the scope in which it 
      was created and in any child scope, unless you explicitly make it 
      private. You can place variables, aliases, functions, or Windows
      PowerShell drives in one or more scopes. 

    - An item that you created within a scope can be changed only in the 
      scope in which it was created, unless you explicitly specify a 
      different scope.


If you create an item in a scope, and the item shares its name with an
item in a different scope, the original item might be hidden under the
new item. But, it is not overridden or changed.