If you collect two event handler dispatches `HA`, `HB`, on DOM nodes `A` and `B` respectively, and `HA` causes `B` to be destroyed, `HB` should still fire, even though `B` is destroyed.

The reasoning is that the event _still_ occurred on `B` so any handlers should be notified of it. If `HB` relies on `B` being in the DOM, then there's nothing we can do because your app doesn't understand itself. But if your app follows the reactive pattern closely, it would be unlikely that `HB` actually does rely on `B` being in the DOM. (BTW: You can still obtain the DOM node related to the event via `e.target`.

What's even better about first aggregating all the dispatches `HA`, `HB`, is that if `B` is destroyed, but replaced with `B'` that has its own registered handler `HB'`, we will not mistakenly fire `HB'`. In other words, I feel like this pattern works nicely with reactivity, and adds no additional nuances to your app that weren't already there.