That's true. At present, the registries do include info that is not in the dataId. The raw image registry has fields (id, hdu, instcal, wtmap, object, visit, taiObs, filter, ccdnum, dqmask, date, ccd, proposal, expTime) while the calib registry has fields (id, filter, validStart, path, calibDate, ccdnum, validEnd). Something occurs during ingestion to populate the registries with this information, and subsequent Butler calls can get data based on them. In practice, a common behind-the-scenes check that happens when processing begins is that the calibration product valid dates include the raw exposure's date.
So I guess ideally there would be a test to see if whatever additional header metadata is read during ingestion (e.g., date) lands in the registry appropriately (e.g., try retrieving something with the Butler based on date alone?). It wouldn't surprise me if this fails, though, because one also has to specify a bunch of arguably extraneous information as you've discovered.