I am surprised that this has been broken for as long as hit has. I find that this issue makes -WhatIf a very dangerous parameter. A module author should not need to be aware of the fact that they command they are calling is in a binary module or a script module. But to correctly implement SupportsShouldProcess, they absolutely must know when they are making calls to a script module so they know to call it with -WhatIf:$WhatIf or wrap it behind a call to $PSCmdlet.ShouldProcess.

The real danger is most people don't realize it works this way.

Agreed. This issue renders every common parameter effectively unusable for script module authors whenever they call commands external to their modules because most authors will not understand why some commands work without issue and others completely ignore the requested preference.

I can only hope we can get it approved for a fix as soon as possible.

Stumbled across this today as well when I refactored code into a common script module where as a result of that the $WhatIfPreference was not propagated any more to the function being called. This is a serious bug IMHO and I don't see how fixing this would break other people's code, even if someone relied on $WhatIfPreference actually not being propagated then it should be an easy fix anyway.

@joeyaiello @SteveL-MSFT is this one one your guys' radar at all? 💖

I am following the rabbit trail from Powershell\Powershell#4568, and am trying to solve this as well. I see DWyatt's "Get-CallerPreference" script, and am thinking of using something similar for now.

There is an edge case to this proposal that may need considering. I have a module with a cmdlet(Adv. Function), that contains verbose messages to call out information, and is called by other higher-level cmdlets a lot of times (possibly hundreds of times). When I do -verbose from the high-level cmdlets, I don't want these chatty verbose messages to be forwarded, so I use -Verbose:$false in the higher-level cmdlets, to disable this from happening. (TBH, I can't recall if -Verbose:$false is even necessary, but I use it.)

IMO, I think opting-out of passing these preferences would be useful. But by default, I would like to see "Calling cmdlets" pass their preferences onto the "Called cmdlets". Mostly, because there isn't a preferred/documented/best-practice way to make this work currently.

@bwright86 I can see that potentially being useful, but I think at least as an initial implementation it would be preferable that it affect everything; as you note, those authors can selectively pick and choose which cmdlets' preference variables are passed along by simply manually overriding the -Verbose (etc) params when their function calls other functions.

I'm not sure a completely separate preference is necessary, but if it does end up being desirable I could see potentially something like an additional property in CmdletBinding to modify the behaviour would perhaps be one way to go about it.

I agree with you, and I think what is being pointed out by this RFC and many SO questions, is that there isn't a good way to code the preferred way. So if this RFC goes forward, it would be nice to document the "opt-out" way for the use case i mentioned.

So I wasn't looking for anything to be implemented from my edge case, but maybe something to keep in mind, or integrate into the RFC language.

I think manually overriding the preference like you mentioned may be a good way around it, and calling it out in the CmdletBinding() attribute could be interesting.

As a side note, the issue I was facing today that caused me to go down this rabbit hole, was the -InformationAction variable. But it turns out that I was using a Write-Host in my lower-level cmdlet, and the documentation does call out that an Ignore flag can be used to filter these out. So more to learn on my side around this.