Yeah, I tried it without the time restriction, and still couldn't get it to not add the second event, or even change the State so that it didn't trigger the notification, so it's probably best to get rid of that business rule and let the events get added.
I hope I'm not leading you down another rabbit hole, but I stumbled upon something that seems to be getting us closer. In your business rule that is calling the event on deletion, change the call to this
gs.eventQueue('group.membership.delete', current, current.group.name, current.user.name, 'group.membership.delete');
That last parameter will put it into a queue so it won't process. Incidentally, without this I was seeing the event error out and the notification not trigger since it was trying to process on a record that no longer exists, which makes sense I guess. In any event, now we haven't done anything to trigger a notification, but we have captured each name (or ID, or whatever you want) that was deleted from each group, and the date/time stamp, so that seems like progress.
Does the group manager need to get the notification right away? If not, you could have a scheduled job that runs nightly against the sysevent table and pushes all of the names into an array for each group for that day, then calls a new event which is what would cause the notification to trigger. The scheduled job would change the state and/or the queue so that they don't get picked up the next time, so you could run it every hour or whatever and not mess with time ranges.
