With the increasing flexibility offered in automations, there is a trend to try to reduce the number of automations by using multi or wide triggers, and handle the specifics in conditions / actions.
Unknowing to most users, and with the current “single” default mode, this might lead to automation triggers being lost, due to the automation already running.
As a default leading to potential loss of information doesn’t seem pertinent, I would suggest to use “queued” as default mode, which prevents this.
I’m sure, but that wouldn’t be the first “breaking” change, would it?
Not really sure someone expects the single behaviour for an automation, either, tbh. I don’t really see a use case where queued wouldn’t work, so I’m not even convinced it’d break anything.
Actually, thinking back, the way it used to be, before we had modes it worked like this:
If an automation re-triggered while it was running it would skip any conditions and go straight to the actions. So sort of like restart mode but without the condition check when restarting. It caused quite a bit of woe.
I use single mode extensively to prevent multiple notifications by simply including a delay of the required period between messages at the end of the actions. Changing this to queued mode would necessitate a fair bit of editing to specify single mode for each. So I like it the way it is.
