So I'm not keen on having to update the reference catalogs everywhere they exist, if we can avoid it. And I think that sort of change does require an RFC, as I don't think we can modify any of the files in the common repos (or even add to the common repos) without an RFC.
However, I was looking at the issue at hand (if affects FGCM as well, also uncaught by the tests using the a.net catalogs in testdata_jointcal), and it seems to me that there's an unfortunate mix of the Sigma -> Err change with the flux -> instFlux change (which is indeed getting inappropriately applied here), combined with the fact that getRefFluxField (https://github.com/lsst/meas_algorithms/blob/6a7bfb3b1a1aa5a3c7ece46c8b3bedbd1fa687c3/python/lsst/meas/algorithms/loadReferenceObjects.py#L40 ) is ignorant of the change. Therefore, when calling (e.g.) loadSkyCircle it returns a flux field (g_flux) that is the correct field, but now g_fluxErr no longer works: there was a brief and harmonious window of time when g_fluxErr -> g_fluxSigma but now it thinks that g_instFluxErr -> g_fluxSigma which breaks everything.
A fix that I think would work (but would be a bit ugly, and I could see people yelping) would be to update getRefFluxField to use instFlux if it finds it. If this was first on the list, it would grab this (erroneously named, yes, but workable and completely internal-facing) instFlux from the aliases and everything would continue as normal. With future, updated catalogs, then the version/type would be updated, and it would never find instFlux in the schema.
Another possible fix, though I don't know how the aliasing works, is to do "two-stage" aliasing for each of the Sigma -> Err and flux -> instFlux updates. Then for each band the schema would look like 'g_instFlux'->'g_flux', 'g_instFluxErr' -> 'g_fluxSigma', 'g_fluxErr'->'g_fluxSigma'.