DEPLOYING WINDOWS 10 APPLICATION CONTROL POLICY

So I learnt the hard way that doing the following is bad news:

• Creating new rules from audit logs into their own XML
• Merging the new XML policy into an existing supplemental policy, with the existing policy second in the list of policies to merge.
• Converting the policy to a BIN and then deploying it online.

Doing this (specifically the merging in the wrong order) caused the following:

• The new policy was a base policy with a new ID and no other related supplemental policies.
• Targeted devices now had two base policies present.
• Everything (I mean everything) started getting blocked.
• After restarting, all devices went into blue repair screens and couldn't reach windows.

We resolved the issue by following the Microsoft documentation for https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/disable-windows-defender-application-control-policies#remove-wdac-policies-causing-boot-stop-failures:~:text=Remove%20WDAC%20policies%20causing,Restart%20the%20computer.

One at a time. For many, many devices.

After this eye-opening event, I have done some more digging and now discovered the setting mentioned above for "10 Enabled:Boot Audit on Failure". 

If this had been enabled on (both) of the base policies, we would have still been able to allow users to access Windows and receive the rolled back WDAC policy.

However, my questions is:

If we turn on option 10, does something actually jump out and alert us that devices are now in Audit mode because of a boot failure event?

If not, don't we risk not noticing and our baseline policy being in a prolonged state of audit mode?

Thanks!