Some ideas to try:

• Re-frame DimensionGraph with Dimensions as nodes and DimensionJoins as a special kind of edge; add traversal iterators of various types.
• Make DataId standardization go through a factory function instead of the constructor to avoid the need for _new_. Might need to make this a registry method to provide automatic expansion and that extra level of indirection discussed above; are there contexts in which we need to standardize a DataId but don't have a Registry?
• DataId (and perhaps DimensionGraph) should more explicitly track which implied dimension links are known. Or perhaps (if standardization always goes through a Registry) all implied dimension links should always be known?

Should also address here a comment from Nate Lust on DM-17048:

Not a problem for this ticket, but it would be nice to have a ticket for someone to go back and add a lot of comment lines describing what is happening and why in conceptual terms, as it is hard to do anything but see the code right in front of you with no understanding when someone opens this package.

I believe this most pertains to selectDimensions, but it's good advice more broadly as well.

Right now ExposureRange is the only Dimension with two keys, but we'd want to fix that (DM-16539) even if we didn't want to eliminate the distinction between dimension name and link name.  Marking that as a blocker.

This ticket is still a major refactor of the dimensions system, and many of the original motivating factors are still very much motivators, but the "ideas to try" are pretty out of date, and some of the motivating factors have already been addressed on other tickets.  A more complete writeup of what will be changing is forthcoming - I'll be putting as much of that makes sense in as actual code documentation that describes the new system (not so much as a diff against the old one).  In the meantime, take the original description and previous comments here with a grain of salt.

The megaticket is almost passing Jenkins and is ready for final review.  Once again I'm trying to split it up between Tim Jenness and Andy Salnikov, and since there are a lot of packages but also a lot of code that has already been reviewed, I'll point out the commits that are new and who I'd like to look at them:

• daf_butler: new commits for both; see comment on PR.
• obs_base: already fully reviewed (by Tim); only changes are addressing the last review.
• pipe_base, meas_base, pipe_tasks, skymap: Andy, all commits new.
• obs_subaru: mostly already reviewed by Tim; one new commit for Andy.
• obs_decam: Tim, all commits new.
• ctrl_mpexec: Andy, all commits new.
• ci_hsc_gen2: already fully reviewed (by Tim); only changes are addressing the last review.
• ci_hsc_gen3: Tim, all commits new.

It's also possible there will be an obs_lsst branch added later, if Tim lands Gen3 support there before I can break his branch .

I checked all PRs that are assigned to me, everything looks good. Removing myself from reviewers.

I had some minor comments on the pull requests. This is an amazing piece of work.

Alrighty, three more packages with changes, so one more extra-final set of (trivial) reviews:

• Andy Salnikov: obs_cfht, obs_ctio0m9 (more of the same config overrides for reference catalogs you saw before)
• Tim Jenness: obs_lsst (config overrides for reference catalogs and API change updates for the new Instrument classes)

I approved both PRs.