daf.butler.registry.queries is getting creaky and hard to work with; usage patterns and needs have slowly diverged from what it was originally designed to do, and it's accumulated a lot of bad encapsulation, tight coupling, weird and hard-to-document method preconditions. This has gotten bad enough that it's very hard to include support for querying CALIBRATION collections on DM-24432 without major changes.

We also have a number of related changes on the horizon that we should at least consider in any cleanup or refactoring we do now:

• We need to make additive changes to the dimensions system (adding new dimensions, adding new metadata columns) less disruptive in terms of schema versioning.
• We have discussed replacing the commonSkyPix/HTM-based spatial joins with a system where the user explicitly declares up front the combinations of skymap, instrument, and skypix systems they want to use together, and then we just instantiate those relationship tables up-front. That should make for faster queries, simpler query code (no trimming of query rows in postprocessing) and perhaps more configurable flexibility in the future for the kinds of relationships that can exist.
• We need to be able to give users more control over which variants of at least some spatial relationships are used in a query. The use case we have is "give me all visit+detector data IDs for which the visit overlaps the tract, even if the visit+detector doesn't, and all HTM IDs at some level that overlap that visit+detector even if they don't overlap the tract", but I'd like to frame that problem in a more abstract sense before trying to solve it.

This ticket is only for design/prototype work, not actually implementing all of the above changes on master.