In current code, each metadata version has provisioned one range to delete when it is retired. Registering a second range would require copying the metadata to a new version (if there is no other event that required the copy), a potentially expensive operation. Keeping a list of ranges for each metadata version would simplify the code and avoid otherwise-unnecessary metadata copying.

Furthermore, the event-managing code has a race in which a deletion could fail while the requester is not waiting, resulting in the failure not being reported to the requester, and then, possibly, in-migration to a range currently occupied.

Solving this requires plumbing range deletion event notification through more levels of interface.