[Chris McDonough]
... I'd really rather just figure out why the code is failing in the first place. I'd just rather not mask the problem until I understand the cause. That may never happen, of course, but a man can dream.
I definitely want to know it if there's still a way remaining to provoke conflict resolution into creating insane BTrees, although I only care if it's a most-recent version of ZODB (3.1.5, 3.2.1, or HEAD) (earlier versions have known, relevant bugs that have been fixed). BTrees appear sensitive to tiny timing holes just because they're complicated data structures and are involved in conflict resolution a lot. But apart from the bugs in the BTree implmentation fixed a loooong time ago, no other "corruption bug" we've squashed since then actually had anything to do with BTrees -- they were general timing holes that could corrupt anything at all involved in conflict resolution (generally hard-to-provoke failure of invalidation to keep caches consistent).