This is related to #5148.

It's time for -Debug behavior to catch up to 2018.

Since -Debug was added to PowerShell, it has always set DebugPreference to Inquire, resulting in users being prompted to continue execution of a command or not whenever a message is written to the debug stream. If you decide to suspend execution, you are brought into a nested prompt (not the debugger), where you can look at state inside of a nested prompt, test variables, etc., but you cannot see where you are in the code, or use debugger features. In a scripting language that has a debugger with different types of breakpoints, a native Wait-Debugger command, and an Enter-Debugger command from a community module, the usefulness of the Inquire behavior is nothing more than questionable.

The current behavior gets in the way when you want debug information for a specific command. For example, if you are invoking a script, or maybe some compiled code, that invokes a command that is causing you some issues, and if that command was written to include debug output, how do you get the debug output for only that command? If you own the code you can set $DebugPreference to Continue right before you invoke the command, but if not you need to set that variable at a higher level, which can result in the generation of a lot of noise. Wouldn't it be much better if you could simply use $PSDefaultParameterValues to set -Debug to $true for the specific command you need debug information for? You can do that, but the result is that you'll get prompted to continue execution, which isn't user friendly at all. So command authors either need to get used to getting too much information, or use the verbose stream instead, but verbose has a different intent: to provide the command invoker with additional details that may help them troubleshoot what is going on when the command fails.

Try this for fun:
Import-Module AzureRM -Verbose

How much of that information is useful to the person invoking the command? How much of that information would be better targeted towards a debug stream, to help the command author figure out why something is happening when they don't have access to the environment where the command is invoked? The current design outputs way too much information to the verbose stream to be useful, and outputs nothing to the debug stream (because in practice, command authors don't use the debug stream because -Debug is not useful).

The AzureRM PowerShell team requests debug output of their commands by asking the user to set $DebugPreference to true (as described above). Instead it would be much better if they could simply ask users to invoke the command with -Debug, or if the command in question is part of a larger script or command that they cannot modify, use $PSDefaultParameterValues.

The -Debug parameter would be 1000x more useful if it resulted in DebugPreference being set to Continue instead of Inquire, so that users and command authors can have multiple levels of logging in PowerShell. Debug logging is important when you really want to see extra details that you rarely want to see, or when you want to send debug information back to the author of a command. Verbose logging is important when something isn't quite right and you can't figure out why from the error message, so you want some more details to try and figure out what might be going wrong. Each of these need to be useful independently from one another, without end users getting caught up in ridiculous prompting asking them whether or not they want to continue execution of the command.

Further to this, the Inquire action preference functionality should be deprecated entirely, and replaced with Debug, so that users can enter the debugger the moment any type of stream output is generated (e.g. imagine being able to invoke a command with -ErrorAction Debug). Nested prompts are just not useful anymore, and users should never be prompted to enter them when they want debug output.