Explicit creation of preference variables in descendant scopes should be appropriately type-constrained, as in the global scope / according to the definition of the preference variable

[mklement0]

Currently, preference variables, such as $VerbosePreference, are only predefined in the global scope, where they are type-constrained, such as to [System.Management.Automation.ActionPreference], which ensures that only valid values can be assigned to them.
Some preference variables, such as $OFS, aren't even predefined in the global scope, although their type (and default value) is known, as described in Get-Help about_Preference_Variables.

By contrast, assigning to a preference variable in any descendant scope implicitly creates a new variable that is not type-constrained, which effectively allows assigning invalid values.

Therefore, assigning invalid values in scripts may go unnoticed.
(It seems that PowerShell quietly applies a given preference variable's default value in the event of encountering an invalid value.)

Steps to reproduce

$VerbosePreference = 'ThisIsAnInvalidValue'
& { $VerbosePreference = 'ThisIsAnInvalidValue' }

Expected behavior

Ideally, both commands would complain about the inability to convert string 'ThisIsAnInvalidValue' to type [System.Management.Automation.ActionPreference]

Actual behavior

• The first command fails, as desired, because the top-level $VerbosePreference is type-constrained to [System.Management.Automation.ActionPreference], and converting string 'ThisIsAnInvalidValue' to that type fails.

• The 2nd command is quietly accepted, because assigning to $VerbosePreference in the child scope created by & implicitly creates a new, local variable that isn't type-constrained, so it effectively becomes a [string] value that cannot be converted to a legal [System.Management.Automation.ActionPreference] value.

Environment data

PowerShell Core v6.0.0-alpha (v6.0.0-alpha.17) on Darwin Kernel Version 16.5.0: Fri Mar  3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64

[MatejKafka]

@kilasuit Still relevant, please reopen.

Got bitten by this today. Inside a binary cmdlet, I needed to get the value of a preference variable. I assumed that when I run SessionState.PSVariable.Get("ErrorActionPreference"), I'll always get a valid ActionPreference value. I'll update the cmdlet to be more defensive, but it would be nice to get this fixed.