I believe it’s because a
timer is an entity, that only gained the ability to be restored this year, whereas
wait_template, etc are scripting statements within an
automation entity and automations that are in-progress are not resumed after a restart/reload.
Restoring a timer simply involves computing the remaining duration. In contrast, restoring an automation would require keeping track of which statement was being executed when the automation was stopped. Then it must determine what remains for that statement to do. For example, if it’s a
repeat - count how many more iterations remain. If it’s a
delay then how much longer to wait. It gets more complicated for other statements that are monitoring other entities (
wait_template) because, after a reload/restart, those other entities may have already changed state.
The situation would be mitigated by the introduction of incremental reloading. Only a new/modified automation would be reloaded and all other in-progress automations would remain undisturbed. Only a full reload, or a restart, would stop all in-progress automations and reload them. There’s an existing Feature Request for this and at least one other WTH.