I suppose I am in the mindset the toolkit is a library and not a framework. I have this dream that I leave your toolkit in its own base folder and folder structure and when you do an update, I copy all the files from your new version into my project in the same structure and all my custom classes will not be affected or know anything changed and it compiles in one click with no other changes, only that I can add extra functionality from the parent now if I desire to in my custom child blueprints. You are starting to shatter those dreams from the sounds of it, heh.
Really getting into the project now with another developer and after dealing with something as simple as trying to change your base UI, if I no longer developed around the idea of not changing base toolkit functionality, things like removing the base ui calls wouldn’t be a concern. At the end of the day though, my dream is I can develop content while retaining your base kit functionality, because if and when you release an update, it will become exponentially more difficult to merge your new functionality into my child classes (or modified base toolkit if I stopped with this child blueprint ideology).
It seems inevitable for a production game the toolkit would become no more than a basis of foundation and learning if I go down this path of over writing base classes and I only just started to learn how it all works. So… til I cut ties with the base toolkit, I am trying to hold on to modifying anything core.