Background

WT-17254 makes a layered follower cursor's remove with overwrite=true write a tombstone into ingest whenever the key's local (ingest/truncate-list) state can't confirm it's already removed – including the case where the key actually only exists in stable, or doesn't exist anywhere. In that case, the leader's own delete for the same key (if one exists) will also eventually arrive at this follower through the normal replication/checkpoint pipeline, potentially landing a second tombstone on top of the one written here.

WiredTiger's layered table code does not currently handle two tombstones on the same key correctly.

Proposal

Support two consecutive tombstones on a layered table key landing from independent sources (a locally-written blind remove, and a replicated delete arriving later via checkpoint) without corrupting the ingest table or tripping the drain-time invariant.

Impact if not fixed

Until this is supported, callers (including test/format) must avoid relying on overwrite=true remove in scenarios where a redundant tombstone could later collide with a replicated delete for the same key. See WT-17254 for the originating context.