As part of WT-5640 chenhao.qu made a change to squash multiple subsequent tombstones on an update chain. There is an open question about what scenario leads to having multiple tombstones in an update chain. That ticket is closed, so moving the conversation here to a new ticket.

I only see this in test_wt2323_join_visibility.

chenhao.qu it seems as though your explanation for why it was safe to ignore multiple tombstones wasn't correct. Could you explain what testing scenario this is handling?

I would generally not expect multiple subsequent tombstones in an update chain. I'm also concerned that your change is going to mean that the content we have on disk has invalid timestamp ranges in it. Shouldn't we use the start timestamp of the newer tombstone as the stop timestamp for the previous entry in the history store, and with this change we'll use the start timestamp for the older tombstone?

There are also a number of cases we've introduced recently where having a pair of tombstones has special meaning. Squashing them here as your change does feels risky.