Motivation

On the WT side:

• Positioned cursors: stable lookup already skipped, no change needed
• Unpositioned cursors: this is where blind writes would help with standby performance

From mongod's side:

• Collection deletes: always positioned (explicit stable reads), so blind writes won't help
• Index key deletes: mostly unpositioned, so this is where the benefit would be

So workloads with frequent index key modifications (TTL indexes, updates on indexed fields) would benefit from blind deletes.

Final design

• No new cursor option: overwrite=true on WT_CURSOR::remove is the trigger, matching how overwrite already behaves for insert/update.
• On a follower of a layered table, overwrite=true requires the caller to guarantee that the key given to WT_CURSOR::remove exists – a caller guarantee, not unconditional success for an arbitrary key. Because of that guarantee, the stable lookup is skipped entirely for the existence check; only ingest and the truncate list are consulted to confirm the key isn't already deleted locally, and the tombstone is then written directly.
• Diagnostic builds assert (crash) if a tombstone is already confirmed in ingest, or the key is covered by the truncate list – that is a caller contract violation, not a tolerated no-op.
• If the key's local state can't be confirmed either way (not found in ingest or the truncate list), it is trusted per the caller's guarantee and the tombstone is written, the same in diagnostic and release builds. Verifying that case independently would require consulting stable, which this path deliberately skips in both build types; the assert above only covers what ingest and the truncate list can confirm.
• A write conflict with a concurrent, not-yet-visible change to the same key (the same check that already applies to insert/update, independent of overwrite) can still fail the call with WT_ROLLBACK.
• This settles the caller-guarantee model raised in review: removing a key that never existed anywhere is a caller bug, not defined-harmless behavior. Because test/format's own removes aren't leader-confirmed before replicating, it continues to force overwrite=false around its disagg follower removes; WT-18043 (still blocked by WT-18042) tracks enabling overwrite=true there once double-tombstone handling exists.
• WT-18019 tracks extending the same "overwrite=true requires the key to exist" behavior to standard (non-layered) cursors.
• WT-18042 tracks the known limitation that WiredTiger doesn't yet correctly handle two tombstones landing on the same key.