The hub spends most of its time doing nothing, waiting for a scheduled event to occur. The hub is event driven, and is really overpowered for most home automation.
Given that, a primary goal when designing a Rule (or any code) should be to make the intent and flow clear, so that, when you come back to the rule to make changes, or to debug unexpected behavior, it's straightforward to understand the Rule (or code).
Of course, you are an experienced programmer, and know all of this. Your contribution to the community code base is great. I make extensive use of HADB.
My first choice would be option 3, easiest to debug and change.
Adding to the above, which is all both true factually and in line with my own opinions otherwise, my preference is #2, assuming you mean adding a "Delay" or "Wait for event: elapsed time" action to your rule (my preference there is always the second, even though the first is slightly easier to find, unless you don't want re-triggering to cancel the delay and restart if/when reached). Just to show you there's more than one way to do it, sometimes a matter of art and not science.
Option 1 actually seems the worst, as that will create multiple scheduled jobs, one for each action -- again well within the power of the hub but more work to create for no better outcome.
Option 4 is also temping if you prefer custom apps!
For me, even though it would be well structured, option 3 has the desadvantage of having to deal with 2 separate rules. I don't like to go back and forth between screen to view the sequence of actions.
This was the primary reason I ask the question.
I'm not sure I see the difference between these two. Both delay the rule for the amount of time specified.
Not to argue, because, at some level, itās a matter of style, my preference for option 3 is that it compartmentalizes all of the delay issues in one place, and compartmentalizes all the things that happen after the delay in another.
The list of things to be done after the delay can shrink and grow without being distracted by the logic surrounding the delay.
Likewise, the factors that determine the delay can become more simple or more complex without being distracted by the actions to be initiated after the delay.