Precisions on the proposed change, which the description does not mention:
Only the events produced from observation.remote.reclaimMaxAge (1 day by default) before the member left are taken over: older events of that member stay undispatched (their number is logged). This avoids old alerts and immediate live mails for old events after an upgrade of a cluster which ran with changing identifiers. The events produced up to observation.remote.reclaimDelay after the departure (as seen by the cluster singleton node) are included, so that a clock difference between the members does not leave events behind.
The pending live notification mails are resumed first, then the undispatched events are dispatched, each member being taken over once while the same member is the cluster singleton node. The events of each member gone for good are queried separately, so the number of such members does not change the size of the queries.
Mails can still be sent twice in these cases: a member which comes back while its mails are being taken over (each user and each event is checked, but the mails already queued by the cluster singleton node are sent by it), a change of cluster singleton node during a take-over, a network partition longer than observation.remote.reclaimDelay, and an event whose dispatch was interrupted after some of its mails were created (an existing limitation, the same as at a restart).
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.