This happens because in the current version of Telerik, the IsTopmost of the ToolWindow that host the floating pane is set to True. That was needed for a related new functionality, but it brings a major behavioral change in the RadDocking control.

To work this around, you can subscribe to the ToolWindowCreated event of RadDocking and set the IsTopmost property of the creating ToolWindow to False.

private void RadDocking_ToolWindowCreated(object sender, Telerik.Windows.Controls.Docking.ElementCreatedEventArgs e)
{
    var window = (ToolWindow)e.CreatedElement;
    window.IsTopmost = false;
}

Regions in panes content are not resolved when the pane is unpinned and collapsed. This happens only when you change the regions in runtime while the pane is unpinned and collapsed.

Panes that are autohidden are cut if resized too much - this is due to limitation in WPF that popups should not cover more than 75% of the screen.

When a Pane is floated and added to a specific position in a PaneGroup saving the layout saves its position as last Pane in the group

If the Background property of a RadPaneGroup is set in Windows8 and Office2013 themes it is disregarded

If the mouse is above an AutoHideArea while the theme of the control is changing an NullReferenceException is thrown.

The Docking control must be placed inside DataTemplate.

Also it is possible to reproduce this behavior by executing this process:
  - Load a previously saved layout into the RadDocking control (note that the PanesSource is not set)
  - Set a PanesSource collection. Here the PanesSource objects are correctly added to the control but the previous items from the loaded Layout are not removed.

The RestrictedAreaMargin should be used as a starting point for the position when a ToolWindow is being maximized.

After certain expand/collapse of RadExpander that is placed inside a floating RadPane the DataContext of the RadExpander is lost

Changing the pane's state using context menu from floating to tabbed items leads to memory leak in MVVM scenario.

Available in LIB version 2016.2.530, it will be also available in the 2016 R2 SP1.

Currently TabStripPlacement property is not stored on a RadPaneGroup as part of the xml when calling SaveLayout. The result is when this has been set to say "top", loading the same layout then causes all docked panes in the group to switch tab placement to the default of bottom - which is not the same as it was.