playing with new ways of defining data/props of components for the project(s) I came again to a burden of messing with “AssociateReference”/template when loading components from Factory, it always blew my mind, but somehow I managed do make everything working.
I see this instrument as really helpful, but every time I have to re-analyze the asteroids example to grasp interconnections of all involved elements, and “translate” to my case. Many times I did that Associate and it worked in result, but requires to be really cautious what you do, so I bumped into long debug/adjust sessions with the code (which is also interconnected with other parts of game, not always easily separable as in asteroids example).
So this time I decided to investigate the code behind it and analyzed castlecomponentserialize.pas and factory class. It made it clearer, but also wondering, if it could be done better (to my opinion).
The main goal was to make a factory which would accept a class with extra defined properties (like button with a bunch of images on it, which I want to control via logic in this same class). The standard Associate-approach only defines a set of references which are not really connected to a button, and code looks unnaturally (esp who owns what, how to access, for example, from button onclick those props listed in associate and so on). One smaller additional goal is to make it work independently of “editor with custom components” feature, as it requires rebuilding of Editor with Lazarus.
So I made my own version of a factory, which is generic and allows to load an object which is defined by that T and all its properties are accessible in natural way. So you just write
Factory: specialize TCastleComponentFactoryNew<TMyButton> ...
myButton := Factory.load(owner)
myButton.CustomImage.Exists := false
and you don’t need any intermediate (like Associate), and even RegisterComponent call (which I was surprised to encounter), and you get all the type safety and power of direct accessing properties (no need to assign or copy smth), your component just needs to resemble the design file.
So, here is the branch where CGE changes are done:
and here is usage example
this is not in any way a direct proposal for the engine, rather than just my thoughts on how it could be alternatively (not replacing) working.
Maybe this would inspire a talk or further investigation 
P.S. A note about topic category: it is not directly Editor topic, bc such approach could have profits just working by code as well. But I think it comes with full power when done via Editor and decent amount of factories in your views.
P.P.S. in my code there are CastleFog components (which might be confusing for 2d-ui game), but I find it as a handy approach to define some additional components’ properties in the editor via just storing them such way (and then getting from code, thus avoiding hardcode). It is again about removing the dependency on custom components.