Philosophically, the approach I took in the beginning was that (a) underlying functionality is defined in underlying modules, and (b) it’s attached to the UI via apps in the referenceapplication module (or else you can fork referenceapplication and do your own custom config).
We did not completely follow this philosophy, because were also thinking of the OpenMRS 1.x way where you add a module, and its functionality just appears. Therefore we did also define some apps/extensions in modules like coreapps (and this leads to @themoonraker13’s confusion).
So, the “correct” way to be consistent with our original philosophy would be to remove all definitions of apps and extensions from registrationapp, coreapps, etc, and put them in the referenceapplication module.
Later, Bahmni appeared and took a different approach, which is that instead of a “configuration module” (e.g. referenceapplication or a fork) you would have configuration files.
The Bahmni approach is actually better for our typical OpenMRS use case, because “modify the default configuration json files” is much more approachable for a typical implementer than “fork a module and edit its activator”. And you can still version the configuration files in source control.
Actually shifting to this approach would require some analysis. Now might be a good time to consider it, as we’re working on making the patient summary more configurable.