Suppression can hide the second event
Collapsing repeats keeps a queue readable and also discards the copy that was different. The rule doing the collapsing cannot tell which was which.
Suppression is how a queue stays workable. One alert per host per hour instead of four hundred.
It works because most repeats really are the same thing happening again. The risk sits entirely with the one that is not.
An account trips the same rule eleven times. Ten are a misconfigured service retrying. The eleventh is a person, from a different country, twenty minutes later. Folded into the same bucket, it arrives as a number, and a number does not carry the field that made it worth looking at.
The same shape shows up after a case is closed. New events matching an open incident get attached to it rather than raised on their own, which is correct behaviour right up until the adversary moves to a second host and the new activity lands quietly inside a ticket somebody has already made their mind up about.
None of that is an argument against suppression. It is an argument for choosing the key on purpose. Group on the combination of fields that genuinely defines the same event, and let anything differing on a field that matters through as new.
Find your highest volume suppression rule. Ask what it groups on. Then ask what an adversary would have to keep constant to be counted as a repeat.
CHECK YOURSELF
A rule suppresses duplicate alerts by hostname for one hour. Inside that window, an adversary triggers the same rule on the same host using a newly created account. What does the analyst see?
SHOW THE ANSWER
A count added to the existing alert, with the new account visible only in the underlying events
Why. The suppression key here is the hostname, so everything sharing that hostname inside the window folds into the first alert no matter which account was involved. The events themselves are still stored and still reachable, which is why the answer is that they are present but unsurfaced rather than gone: suppression that silently destroyed data would be a far larger problem and is not how platforms generally implement it. Severity is a separate property that grouping does not touch. The key you choose is what decides which differences survive.