Is this a good thing - that the original value is retained? It seems odd to me that $WhatIfPreference accepts any value and does not coerce it to a boolean value during assignment. I'm sensing there is a PS design principle here for pref vars that I'm not aware of.

This happens to all powershell action preference variable, and actually, all other automatic variables that don't have the "AllScope" option.

For variables that are not 'AllScope', they are not copied to a new local scope and thus an assignment to the same variable in a nested scope actually create a new variable in that scope, which doesn't have the argument transformation attribute as the one declared in the global scope.

BTW, we want to avoid 'AllScope' variables as much as possible because it's expensive.

But for $WhatIfPreference, it's missing the argument transformation attribute, so you can assign arbitrary value to it even in the global scope ... 🤷

This happens to all powershell action preference variable, and actually, all other automatic variables that don't have the "AllScope" option.

I'm not seeing that:

But also, is there an actual reason for that behaviour to persist with this variable? Surely we want to eagerly convert it to a boolean, since the only thing that can happen is that it becomes a landmine later...

This is from 7.2.0-preview.9. The key is a new local scope.

So is this desirable behaviour though? Or is there no way around it and we just need to prevent the error that happens later?

To me it looks like an accidental inconsistency that we should eliminate (but possibly can't because it's a breaking change...?)

So is this desirable behaviour though?

Absolutely not desirable :)

is there no way around it and we just need to prevent the error that happens later?

Making the variable 'AllScope' will prevent it, because 'AllScope' means copy the same variable to every new scope you created. But that's expensive (cost is not necessarily worth the gain), and it may cause breaking changes when it comes to action preference variables considering the existing optimization on those variables.

There could be other ways to improve it, for example, by making those variables aware to PowerShell when creating a new one in a local scope, so the transformation attribute can be automatically added. This is out scope for this PR, but we surely can discuss more about it.

Ok, I'm happy with the changes in here then and will merge