In FLCS only keys off the end of the table are supposed to not exist; deleted values read back as 0. There's logic to sustain the illusion even in the presence of explicit tombstones.

WT-8461 broke this illusion for multiple remove() calls in succession (without page reconciliation between) – we now properly enforce the restriction against issuing consecutive tombstones, and that means that removing a value and then removing it again immediately will produce WT_NOTFOUND (like other tree types) instead of allowing the illusionary zero value to be deleted again.

We decided to not hold up merging the WT-8461 changes over this and to fix it in a subsequent ticket. This is that ticket. The proposed fix is, in the case where there is already a tombstone, to issue a dummy value first and then a second tombstone immediately on top of that.