Gauss2DFit will need Component, Source, Model and Modeller classes. I think the relationships between these in MultiProFit is essentially fine. I may restructure whether Sources or Components store a PhotometricModel (probably Sources), and slightly tweak the AstrometricModel (still only one planned implementation of a fixed, band-independent centroid).
The inheritors and modifiers of Parameters can likely be removed entirely, since these will now all be shared_ptr. Inheritors should just be the same pointer, and the logic for modifiers should live in the relevant Source class.
Many function implementations will change completely. Right now in MultiProFit (python), each Source/Component returns a dict of objects and/or floats, which are then re-interpreted by the Model to actually render images. This is wasteful and the main source of the slowness in MultiProFit. Each Component/Source should instead implement a get_gaussians method that returns a (Parametric)Gaussian, ready to be passed to a GaussianEvaluator. For model fitting, these objects can and should be generated only once prior to the start of fitting, and each fit iteration can simply update the free parameters directly.
In the future, if we want to keep support for e.g. GalSim-based models, that should be possible. I will likely implement renderers as an enum class, and have something like a get_galsim_objects function. In principle, there's no reason why one couldn't mix and match sources or even components with GalSim and Gauss2DFit-based models, although I'm not going to make this a high priority.