Summary of the new feature / enhancement

Reading the (recent) requests for additional automatic variables, I often see the general argument:

Adding an automatic variable might break existing scripts

Which is a valid argument but shouldn't be a valid argument. With nearly 50 automatic variables, this is going to look like a rookie mistake similar to using the <verb>-Variable cmdlets for dynamic variable names.

Most requests for new automatic variables are based on easy access or a clearer syntax. For the latter, I personally prefer the automatic variables as they do not require any parentheses (e.g. in the case of a cmdlet) or square brackets (e.g. in case of a hash table) when included in an expression.

Proposed technical implementation details (optional)

Afaik, a PSDrive reference of a provider might be used interchangeably with variable names:

$Env = 'foo'
$Env:temp
# C:\Users\user\AppData\Local\Temp
$Env
# foo

Which to my opinion means that if the automatic variables are contained by a separate PowerShell provider they shouldn't cause any break changes and even the provider name itself could afaik be something like $PS: or possibly just $: (probably as a syntactic sugar) as e.g.: $PS:Input or $:Input rather than: $Input.

Following the stackoverflow questions and answers closely, I can tell, almost every PowerShell starter falls into the automatic $Input variable pitfall.
Although an automatic variable provider won't fix that for the installed base, it will better allow for additional automatic variables (like $:now).
And in the future, I think it might be possible to remove about 90% of the current (potential conflicting) automatic variable names with an optional environment preference.