John, would you mind giving this a look? I can confirm that the problem has indeed been fixed (having processed all the the NB0921 band RC dataset of DM-6816 through meas_mosaic). If you wanted to test it yourself, you could point to the following rerun on tiger:
lauren/LSST/DM-6816/cosmos and the NB0921 visits are:
cosmosVisitsNB0921=23038..23056:2^23594..23606:2^24298..24310:2^25810..25816:2.
A Jenkins build (of just meas_mosaic) is happy.

So this worries me:

>>> LoadAstrometryNetObjectsTask.ConfigClass

<class 'lsst.meas.algorithms.loadReferenceObjects.LoadReferenceObjectsConfig'>

>>> ANetBasicAstrometryConfig

<class 'lsst.meas.astrom.anetBasicAstrometry.ANetBasicAstrometryConfig'>

You appear to be replacing the former with the latter, but they aren't actually the same. In practice, I think it doesn't matter, since they both have a filterMap and I guess that's all you need, but we should probably fix it. Since I don't think we use config.astrom anywhere other than here, you can probably just change it into a LoadAstrometryNetObjectsTask.ConfigClass. And change the docstring, because it's not being used as a "configuration for readMatches".

Excellent point! I've updated accordingly. I decided to change the name astrom to loadAstrom to be slightly more explicit about the fact that it's just the loader we are using. This required updates to the filterMap config overrides in obs_subaru. I've pushed the updates and tested them locally. A Jenkins build (this time on lsst_distrib ci_hsc meas_mosaic) is running.

Thanks!

Merged to master.