Let's have a TextBox, ToolTip and a FloatingWindow containing the TextBox. The following code snippet will not show a tooltip for the textbox:
            this.toolTip1.ToolTipTitle = "ToolTip";  
            string strToolTip = "Exemple";  
            this.toolTip1.SetToolTip(textBox1, strToolTip);  
            this.toolTip1.AutoPopDelay = 32767; 
            this.toolTip1.Active = true;

Place a RadTextBox on a Form and sets its Anchor to Left, Top, Right. Let's say this form is a MDI child and RadDock hosts it. You will notice that the RadTextBox appears with a wrong size and a part of it is actually invisible.

If you try to set this this.toolWindow4.TabStrip.SizeInfo.SizeMode = SplitPanelSizeMode.Absolute , the TabStrip will not stay fixed if the form containing RadDock is resized. However, if you hide the main document container, this setting will start working.

Let's have a RadDock control hosting several MDI child forms. Set the MDIParent property of these forms to null. The forms will become top level windows, but the HostWindows will not be removed and RadDock will continue listening to the events of the forms. MDIChildren will still contains the forms as well.

When you set a ToolWindow in AutoHide DockState, hover the tab of the AutoHide window and set the focus to the window by a mouse click operation, you are not able to hide the window right after you click outside of the window.

Let's have a form in a host window and then replace (on a button click) the form with another form, using the LoadContent() method. The text of the tab is changed accordingly, but there is no update on the text of the caption.

Control size is wrong when using anchoring in a user control hosted in RadDock.

If you try to close or set to autohide a ToolWindow in ActiveWindowChanged event and the ActiveWindowChanged is fired because you are trying to dock another ToolWindow (currently set to autohide), you may activate the wrong ToolWindow at the end.

Visual Studio 2010 introduced the concept of document windows which behave like a regular tool window. Implement the same functionality within RadDock.

When you try to close a hidden ToolWindow in ActiveWindowChanged, you are prevented from docking ToolWindows which are in AutoHide mode.

OnActivated is fired before OnLoad in forms which have RadDock instances. However, OnLoad should be fired before OnActivated.

Let's have a ToolWindow in a RadDock. Float the ToolWindow and then close the FloatingWindow.
Save the layout, close the application and start it again. Load the layout and display the hidden ToolWindow by calling the DisplayWindow method. The ToolWindow will become docked instead of floating.

After a very specific sequence of steps, you may end up with an xml file of the RadDock layout that contains two windows, although there is only one window at the time the xml file is saved. In addition, when a floating window is loaded, it needs a click in order to get a caption string at the titlebar.

If you have a FloatingWindow with Name and Text set to "TestForm", save the layout and load it, you get a Dockplaceholder with default Name and Text "ToolWindow1". 

If you first dock the FloatingWindow, then float it again and finally save and load the layout, you get information both about the docked and floating windows in the xml.

One should know what is the reason that causes a transaction to take place. For example, if you double-click the titlebar of a FloatingWindow to redock it in RadDock, the user should known that the reason is a double-click operation.

The user should be allowed to modify the default behavior of floating windows and decide whether they should be owned by the main Form or they should act like normal Forms - with Minimize/Maximize options and appearing in the System's Taskbar.

There should be a method which allows the user to host a Form in a HostWindow. This will come in handy when there is a save/load layout scenario.

Resolution: 
Use the DockControl method to host a form. Here is the code snippet: 
Form form = new Form8();
this.radDock1.DockControl(form, Telerik.WinControls.UI.Docking.DockPosition.Left);

When you have a big UserControl in a DocumentWindow and you scroll down this UC, the UC is prescrolled when you try to set the focus on a control of the UC.

There should be a method which hides/closes (depending on the CloseAction) a DocumentWindow. This method should be called from the DocumentWindow instance.

There should be events firing when the AutoHideWindow pops up and collapses.