Here is the latest blend file for completeness. It reflects the change in managing the bsp division bias value.
I think I was thinking in terms of a 'weighted sum' here, hence the somewhat weird math expression.
Biasing toward the previous rather than the first split also seems ok, so fixed.
bbone_primary_split can be adjusted by the above condition checks to ensure the conditions hold, even if somehow they don't hold for segments / 2.
Well, bias cannot be rolled into it cleanly, and it ensures that the ends get the maximum number of bsp splits for symmetry and smoothness.
The return value is not used, but failing the conditions still disables the curved mapping through side effects.
I would hazard a guess on general principles that maybe if there are no non-overlay objects the depth buffer isn't initialised properly and is thus in an undefined state, which naturally depends…
(On a longer term, it's likely best to investigate getting entirely rid of the edit data and special edit mode undo for armatures, it makes really little sense to have it in the first place). …
How would this work with the Python API? The Armature.collections property would probably have to magically choose which list to use.