Recently we have reviewed this item and would like to inform you that with the current implementation of RadDocking loading of the ToolWindow twice in Nested Docking scenario could be considered as an expected one.
The issue is caused by native WPF Window that is used by RadDocking's ToolWindow. When a WPF is shown internally the framework starts to invoke the Loaded and Unloaded events of every control part of the visual tree. RadDocking uses both events internally for visualization and hiding of the ToolWindows. So, when ToolWindow from Nested Docking is visualized it gets loaded as well. That visualization on the other hand invokes the Unloaded event which hides the ToolWindow again, but for just a few moments because the Loaded event is invoked and the ToolWindow is loaded for a second time. Currently, modifying the logic in the Loaded and Unloaded events is not possible - a breaking change will be introduced to the control and some more serious issues might occur.
However, we are glad to inform you that there is an easy workaround that could be used in order to resolve the issue. First, the ElementLoading event needs to be handled for the nested RadDocking. Inside it the IsInOpenWindow property of the SplitContainer that will be visualized as ToolWindow needs to be changed to False. That will prevent visualizing the ToolWindow during the Loading of the layout. After the layout gets completely loaded you just need to iterate through the Panes of the inner nested Docking and visualize the ToolWindows - that way the ToolWindows should be loaded just once.
The described approach could be checked in action in the attached file "DockingWPF.zip".