There appears to be a long-standing problem with back-bdb and entries with more than BDB_IDL_DB_MAX immediate children. If the entryIDs of the children are non-contiguous, then attempts to delete the subtree of the entry will fail, because the IDL range for the OneLevel index in the dn2id DB will never zero out.
back-hdb doesn't have this problem.
Not sure what an appropriate fix is. Ideally, when deleting an entry whose ID corresponds to either the lower or upper bound of the range, we should update the range with the ID of the next remaining sibling. But there's no easy way to search for that ID, so we just increment/decrement the range by 1. The OneLevel index is the only structure that can quickly tell us what the siblings are, and it's obviously useless when this situation arises.
The only way to search would be to [inc/dec]rement the ID and retrieve the corresponding entry's DN to see if it is a sibling of the deleted entry, and loop until a sibling is found or we run into the opposite range boundary. On a large DB this will be extremely slow.
Seems like the best fix is to deprecate back-bdb and only use back-hdb from now on.