For myself, the current semantics make sense to me insofar as one-shot alerts behave like HA button
/input_button
objects, also one-shots, whereas condition alerts (and presumably latched event alerts) behave like switch
/input_boolean
objects, state-wise, which matches up intuitively.
I have also been thinking about staged alerts, and wondering if it might be a good idea to separate the notions behind them into two concepts which seem to me to have different semantics: call them severity and sub-alerts, perhaps.
Severity, as I see it, scales linearly, and every stage is a strict subset of the one before it. It’s possible to either advance to a new stage or revert to one before it (although this latter capability may not be used). Possibilities include:
“disk 80% full”, “disk 90% full”, “disk 95% full”, “out of disk space”
“overheating (5°)”, “overheating (10°)”, “overheating (critical)”
“alert”, “alert for > 15 minutes”, “alert for > 1 hour”
and so forth, where each one implies the previous is, or at least was, true.
Whereas sub-alerts I’m conceptualizing as alerts that are relevant because the primary alert is true, but which aren’t necessarily related to each other, and can change state independently.
So here, to use my standard example, we have:
“door is left open”
- “door is left open AND it’s cold outside”
- “door is left open AND it’s nighttime”
- “door is left open AND activity is detected outside”
where the sub-alerts have different and unrelated conditions, but are all conditioned on the parent alert being “on”.
The former seems to be where staging is converging per here, but the latter seems like valuable functionality for the sort of use we talked about on GitHub here.
And conveniently, this latter is attainable right now by defining a condition alert whose conditions include a reference to the “parent” alert as well as its “actual” condition, so as a feature request it would just imply some syntactic sugar in the YAML and a cleaner display of them in the UI.
(Sorry if I’ve been recapitulating the already known, but I wanted to get this clear in my own head.)
…that was where I was going to leave it, but I stopped to get a coffee and now I have a new feature request or pair of them to add, courtesy of my lovely wife.
They’re both about snoozing, and partly my fault because I’d implemented a “snooze” feature for some of our alerts manually back under Alert. 
The first of them is just that the name of the snooze feature is confusing if you haven’t read the Alert2 docs, because the snooze everyone’s familiar with is the alarm-clock kind, and that kind of snooze starts sounding the alarm again when it expires. Whereas the Alert2 snooze doesn’t; the snoozed alert stays acked when the snooze expires, and so the notifications for an already-on alert don’t come back.
So, maybe that could use a rename to make its semantics more obvious to HA-users who aren’t also the HA-implementors?
The other one is for a notification snooze that would have identical semantics to an alarm-snooze, i.e., act like acking the alert and then automatically unacking it again when the snooze period expires?
(This latter is effectively what I set up for our “Clean Laundry Ready” alert using a timer and a couple of automations, so that she could flip the “Busy now; remind me in a couple of hours” switch and defer notifications for that long. This is of course just as easy to implement now with the ack and unack actions, which I’m going to do right now, but it seems like a generalizable enough request that it’s worth mentioning as a possible feature.)