I think if you wanted to really test deep reorg behaviour on mainnet, you’d want to keep mining both sides of the split for an extended period to mimic miners/pools who were being reorged out by an attack would probably use “invalidateblock” to attempt to save the chain they’d already invested in. Having people actively attempting to do replay protection across the split and potentially having hashpower on each side of the fork change as available fees change etc would give fairly different properties vs the current “let’s invalidate some blocks and re-mine them as fast as we can, and then see what happens” thing I’ve got implemented.
To make sure we’re on the same page, I presume the border between “normal” and “deep” reorgs is somewhere around 6-10 blocks?
(If you go up to 288 blocks, that interacts with NODE_NETWORK_LIMITED, and somewhere around/above that number potentially breaks pruned nodes by going back further than the minimum 550MB of block data)