We recently fixed a bug in WiredTiger related to checkpoint causing splits up the tree in WT-9477. That fix was necessary because checkpoint walk doesn't handle structural changes in the tree - so such a split could cause the checkpoint walk to either visit part of the tree multiple times or skip visiting some parts of the tree.

There is code in split_parent that avoids copying across WT_REF structures associated with deleted pages. That code currently allows for the WT_REF structures to be freed while a checkpoint is happening if and only if the split (and therefore free) is done by the checkpoint thread. There is a comment describing why:

    /*
     * Remove any refs to deleted pages while we are splitting, we have the internal page locked
     * down, and are copying the refs into a new array anyway. Switch them to the special split
     * state, so that any reading thread will restart.
     *
     * We can't do this if there is a sync running in the tree in another session: removing the refs
     * frees the blocks for the deleted pages, which can corrupt the free list calculated by the
     * sync.
     */

That reasoning sounds very similar to the prior reasoning in WT-9477, we should review whether it is safe and necessary for checkpoint to free such WT_REF structures during a split.

In the least this ticket should add or find existing test coverage for the code path.

Definition of done: Confidence in the correctness of freeing deleting refs while a btree is being checkpointed.