Function coalesces_with 

pub const fn coalesces_with(new: &Event, existing: &Event) -> bool

Whether new should replace the queue’s current tail event instead of being pushed alongside it, when a backend is appending new to a Vec/VecDeque of pending events.

True for two consecutive Event::Mouse events both carrying MouseEventKind::Moved, or both carrying MouseEventKind::Drag with the same button: a queue owner (winit, the wasm FFI boundary, Headless) can be fed pointer-move/drag events far faster than a consumer drains them, and only the most recent position matters once it does (whether or not a button is held), so collapsing either run in place keeps the queue from growing unbounded (retroglyph#294, retroglyph#768, retroglyph#942). A Drag only coalesces with another Drag carrying the same button, so a button change mid-drag is never swallowed into the wrong button’s position. Scroll deliberately does not coalesce despite also being high-frequency: its dx/dy are deltas, not absolute state, so collapsing a run would discard real scroll distance rather than a stale intermediate value. Every other event kind (clicks, keys, resize, …) always returns false.