FWIW I’m still confused about why maven can’t handle this even if you add
<exclusions>
<exclusion>
<groupId>org.openmrs.distro</groupId>
<artifactId>referenceapplication</artifactId>
</exclusion>
</exclusions>
for each of the dependencies.
We’re using maven dependencies to assemble the distro, but this is actually a bit of a hack, especially once it has been released and refers to fixed versions of modules. At that point, assembling the distro could also be done by fetching them from the module repo, or just downloading them from maven as files, not dependencies. (Or you could try the new SDK features that let you specify a distro’s module versions.)
(Anyway, we all agree this is a mess; someone is going to need to step up and put in the time to work out a solution, or it will continue to be a mess.)
The problem is that this means your past released builds are non-reproducible even if we do solve this maven dependency issue. You can choose to live with this (PIH has), but if so you should really organize your workflows so as not to be rebuilding old released versions, but rather building them in CI and saving the artifact.
What you can do instead (and I recommend!) is that you invest in getting someone the required knowledge and privileges to be able to release new versions of these modules. E.g. that way one of your team members can release a fixed version of the coreapps module with whatever changes you’re requiring, before doing your own disro release. (Bahmni does this with the emrapi module to avoid depending on snapshots in their releases, e.g. here.)