There is some subtlety that arises when the trigger and the Required Expression are looking at the same device event, as in this case. RM should handle this case correctly, barring some bug no one has reported and I haven't seen. In this case, both the trigger and the Required Expression use the same event handler (stHandlerA), and that subscription does not go away when the Required Expression is false (because it's needed to know when the Required Expression becomes true). So that handler has to deal with both cases, the possible change of truth of the Required Expression and the possible trigger event.
The sequence is that if the Required Expression is true when an event for that device attribute happens, it will first trigger the rule (assuming its value would trigger it), and then it will re-evaluate the truth of the Required Expression. If the Required Expression is false, the rule isn't triggered, and it proceeds to the expression evaluation. The net result is that the rule can only trigger if the Required Expression was true before the event, and irrespective of that, the truth of the Required Expression is re-established. If the Required Expression becomes false in this evaluation, then all trigger subscriptions are removed, but this one that serves both purposes is re-established.
