Just don't set a timeout, then it will only move on if the event actually happens. This is what I was going to suggest. You're correct that you can't handle this with triggers alone, but if you trigger on the "first" action, then "Waits" will create the necessary subscriptions and get you where you need to go (if the events happen).
Yes, all waits get cancelled when a trigger event happens, so that isn't a problem. Nor is waiting "forever" per se since a wait just creates a subscription--same as a trigger would do--and then the app/rule sleeps until an actual event wakes it up. But it does bring up a related issue for complicated sequences like the poster's second example: is there ever a time when that sequence could happen, even with a bunch of time passing in between, and then you wouldn't want this rule to do anything since it's been "too long" since the initial event/trigger? I assume the idea is that these events usually happen in this order and you just want to wait until the last one so the light doesn't get turned on "early," for example, but my idea would not handle stipulations like this as-is.
ya the timeouts allow you some control to specify how long is too long, i assume it would still work ok with the timeouts and the extra if's if you want to have a little finer control. but you are right if you don't care than they are not needed.
Better just to check the device with the if.. doing the same thing and less intensive. If it exited the wait and the device is not in the desired state it means it timed out. But f
Good to know how to check directly.