What I’m seeing is that the code to do unconditional removes from history store installs a tombstone update over the top of any existing updates — i.e., it creates an update chain with the tombstone but doesn’t link it to any existing updates already in the tree, so they become unreachable.

__wt_row_modify just swaps its update argument into place. Callers are responsible for pointing to the existing updates in the list. This shouldn’t be an issue for the original inserts into history because we expect them to be new. It would be good to check that, of course.