It is really there important topic and I feel gratitude that you are working on it. But there are too many more basic things that needs to be fixed 
Maybe we (me, Mattias, you, others who interested in this topic) can choose some time when we all be able to discuss all problems together.
Many of the "many more problems" IMO stem from the lack of rules for the architecture and extensibility of the LCL. With regards to docking, I'm fighting the same problem, in variations, over and over again: a lot of abstract base classes have been introduced into the LCL, which only *pretend* that they could be implemented in any other way, different from their first implementation. Some practical problems:
- LDockTree has to use typecasts allover, because the basic node type (TDockZone) has to be extended with new properties and methods, in order to make that base class usable at all.
- The TLazDockZone again is not extensible due to private members, which have to be accessed in a derived class, but are invisible outside the Controls or LDockTree units.
- Adding beforementioned new members to the base class would require, that every existing implementation has to *implement* these new methods as well, and also has to *use* the new elements properly.
- The use of a DefaultNodeClass inside the encapsulated (immutable) default implementation makes it impossible to derive further tree node classes, for e.g. a special TopZone and LeafZone, because only one class type is selectable for the creation of every new node.
Possible cure: use a virtual method for the creation of polymorphic elements, instead of a variable holding one class type.
- The DragManager, DragObject and DragPerformer are coupled so tightly with each other, and with TControls and TWinControl, that it's impossible to change anything without rewriting all related classes alltogether.
- Some objects, like the DragManager, have to be singletons. While a DragManager variable holds a reference to that singleton, it's impossible to exchange that object by a different implementation.
(only to mention some of the most annoying problems)
This is why I *had* to implement my revised docking manager almost from scratch, and currently try the same for beforementioned DragManager and related classes. Obviously this is not a meaningful way to only cure some bugs in the LCL, because it will be hard (who ever would?) extract the really required changes from such a parallel implementation, and to update the existing default implementation in only the really required places. Not to mention the changes to the default implementation, that may occur during development of an alternative implementation, and have to be mirrored in that implementation immediately.
A well thought architecture should allow for alternative implementations *without* touching the basic LCL units. Sealed default implementations, of abstract base classes, should *not* be allowed inside the *same* unit, because they will hide all details, which may prevent an alternative implementation at all. How should something be implemented, when access to hidden (private...) elements of the default implementation or some related class is impossible from a different unit? Such restrictions make it impossible to modify the default implementation slightly, by overriding virtual methods in a derived class, as well as deriving a very new class from the the base class.
Whoever introduces a new abstract base class should be *liable* for the proof of their usefulness, and for a documentation of the *intended* use of that class and their interaction with other classes, so that it's possible to extend that class at all, and to replace the default by a different implementation.
Now I know better, and you may know as well, why I hate the "classitis" as found in the LCL. Some developers like to introduce new classes every now and then, because it *might* make sense to extend these classes later. More discipline and stricter rules are required, so that such extensions *really* can be implemented later.
And a last rant, for now <g>:
I'm pretty sure that *many* people would like to contribute to the LCL, by fixing bugs or by fully implementing rudimentary functionality. Currently the efficiency of such contributors is near zero, due to the lack of documentation of even the most basic details of the current implementation. Currently 10% of the contributors (the team) spend 100% of their time with the implementation, whereas the other 90% spend 99% of their time in exploring the the undocumented behaviour, purpose and relationship of class members.
When instead the gurus would spend only 10% of their time for documentation (better all their time), and let others do the implementation, the efficiency would increase by factors! Currently the lack of documentation prevents even a discussion of possible implementations, because none but the "inventors" of $something know about the intended or actual use and implementation of that $something.
IMO Lazarus is an excellent (counter-)example of teamwork. Such a big project deserves good documentation, so that as many people as possible can do the work, while the managers only have to integrate those contributions and hunt only the most complicated bugs.
DoDi
