Can someone provide a concrete example of same-key reordering or non-contiguous gaps during changefeed replay?

[flxgn]

The docs state that for changefeeds:

"Individual messages will include the message's timestamp. The first time a message is delivered, it will be in the correct timestamp order. However, when there are duplicate messages, the changefeed may not re-emit every row update. As a result, there may be gaps in a sequence of duplicate messages for a key."

And regarding ordering:

"Changefeeds provide a per-key ordering guarantee for the first emission of a message to the sink. [...] Under some circumstances, a changefeed will emit duplicate messages of row updates. Changefeeds can emit duplicate messages in any order."

For my understanding this means reordered sequences like this are possible: [1,2,3,4,3,4,2] (replayed 2,3 and 4) or
gaps like this [1,2,3,4,2,4] (replayed 2, 4 and skipped 3).

I've been trying to understand the concrete mechanism that produces same-key reordering or non-contiguous gaps during replay, and after tracing through the code I can't find one.
The catch-up scan applies proper ordering and does not skip messages.

The two mechanisms I can find that create gaps are:

1. MVCC GC — if protected timestamps advance between first emission and replay, intermediate versions may be garbage collected.
2. OmitInRangefeeds filtering — TTL deletes and remote-origin writes are silently skipped (catchup_scan.go:485).

But both produce contiguous gaps (missing versions from the tail of GC or filtered versions), and neither produces reordering.

My question: Can someone point to a concrete scenario or code path where a changefeed replay emits same-key events out of timestamp order, or produces a non-contiguous gap?