Not that I'm ungrateful, but this is the second time this week that I've spent a good lot of time trying to figure out how to use features of the docking controls that are present in the object model but which they don't actually support. I'm sure there's a good reason to make RadPaneGroup derive from RadTabControl, but honestly, if a derived class doesn't implement functionality that's present in its base class, document it.
RadPaneGroup's derivation from ItemsControl presents a similar issue. It may be an ItemsControl (since RadTabControl is), but you can't populate it via data binding the way you can every other ItemsControl. It's a reasonable restriction, once you search around until you find the blog post that explains why it's there.
But it means that you can't build a UI with these docking controls without breaking the MVVM pattern. This is a significant restriction on how this control can be used. Not that the MVVM pattern is sacrosanct and ought never be sullied, but it's what developers are using, and if a control can't be used with MVVM for some reason, this reason ought to be documented, and prominently - like, not just in the class documentation, but in the Getting Started section. If I'm going to have to break out procedural code to create a view using a control, that's something I need to know up front.