I'm not sure what you mean by "secondary executions". Rules are a script that runs when the rule is triggered, every time it is triggered. Delays and Waits suspend the script for some interval, and under some circumstances the script will restart. Waits are a special case because they entail temporary device event subscriptions. As a general rule, multiple simultaneous execution of the same rule's script is a recipe for failure, and is to be avoided in the way the rule is written. Such simultaneous executions are explicitly NOT SUPPORTED. IF-THEN blocks and Waits in particular cannot survive simultaneous execution as the rule only possesses a single state in which to track the nesting of IF-THEN blocks and the meanings of Wait subscriptions. An inbound event from a device carries no information about the context of the subscription that caused it to be received -- such context has to be remembered in the rule's state.
In accordance with the foregoing, all outstanding waits are cancelled at the beginning of each execution, motivated by the fact that a rule only possesses a single state. The idea to keep track of prior execution states for a rule is inherently not possible.
