I've just thought of this very simple concept to failsafe yourself from getting into wait blocks. Whenever there is a trigger which uses a wait we do the following (uMutex is any unused unit):
WhateverCurrent player has suffered exactly 0 deaths of uMutex.The rest of conditions...Set deaths for current player: set to 1 of uMutex.The rest of actions with waits...Set deaths for current player: set to 0 of uMutex.
Some.

An artist's depiction of an Extended Unit Death
It seems more appropriate to use a switch, because you're just flipping a bit. It's a nice concept, but impractical for complex maps. Sure, this would clearly show
if you have wait blocks, but most people want to run triggers simultaneously, including those which would normally use waits. Therefore, death counters are still the most appropriate way of avoiding wait blocks.
TL;DR: It doesn't stop wait blocks, it stops the whole trigger, which causes the same problem. Death counters ftw.
Since waits are player-specific, a player-specific death counter looks more appropriate than a global switch. Yeah simultaneously, well... What I had in mind when I was posting this was the following. Waits are useful due to their specific to have a memory of their trigger. Sometimes I'm using waits just to skip a trigger cycle and then return to execution of the trigger. Of course everything may be done with death counters, but waits alike current player help to keep triggers number reasonable. Then, if I have some amount of such triggers there is a possibility they will run altogether, but due to the waits specific this will cause exponential growth of wait time. Since I only wanted to skip one cycle I found practical to use a mutex to manually separate their execution.
Another thing I found waits extremely useful is displaying information to the player in complex maps. Let's say there is a number of events which may repeatedly happen during the game. When several events happen at a time it might be useful to delay incoming messages for the player (anyways he can't read them all at once). So I split the actual handling of the event and the player notification in different triggers. And then I got a wait in the "notification" triggers: wait(0) before notification and wait(time) afterwards. That way, waits subsystem automatically queues incoming messages and displays them one after another (maybe in the other order though).
Some.
Methinks an ASM mod just to allow parallel waits would almost be worth it.
None.

SDE, BWAPI owner, hacker.
That's easy. You don't even have to manage any data, just use the padding space ("unknown/unused" in the chk specs) for each trigger performing the wait.
Plus with the ability to run triggers every frame and disjunction in conditions. Settled then! Who makes it?
Some.