We have a RadTreeView with "Visibility" property set to "Hidden".
We add dynamically RadTreeViewItems to the RadTreeView.
If we change the "Visibility" to "Visible" - the RadTreeView is NOT displayed.

Originally this item is logged for scenario with XBAP. Currently we are unable to reproduce such issue with WPF 4.0 and latest version of our controls.
Please open a new support thread if you encounter similar issues at your side.

RadTreeViewItem.RootItem returns an incorrect value (reference to itself).

The bug is logged incorrectly. The Root Item will return correct value once the containers are generated after load or dragdrop operation.

The scenario for which the bug was logged checks the root item immediately after insert operation but the containers are not yet generated.

Currently the CheckedItems collection contains items with CheckState "Indeterminate". The change can be controlled somehow since the modifying the behavior now will be a breaking change.

Please avoid using this collection, it is has never been implemented completely.
In DataBound scenarios, add CheckBox in ItemTemplate like it is shown in this help article.
http://docs.telerik.com/devtools/wpf/controls/radtreeview/how-to/howto-tri-state-mvvm.html 

The TreeView should be able to figure out the Old / NewValue for its event args during editing.
====
======

Reason for deletion. In databound scenarios e.OldValue and e.NewValue refer to the same instance of the ViewModel which is expected. 

Saving the state of the ViewModels means creating an entire deep copy of the ViewModel. We believe there is no such control in the framework to save the states of its ViewModels during editing.

We have to admin, introducing public properties OldValue and NewValue of type objects for these event args is a bad design. This is a bug since these are public but we won't fix it due to the complexity (described above).

When the IsVirtualizing property is switched on runtime (for example as a result of applied binding) the generatedContainers are not updated and potentially will not return null when a container exists.
===
Marking this Declined: There is no such public collection. Too old item with only a single vote (like).

It was suggested that the ItemTemplates in the tree view should update when the item template selector or the item template is changed.

This will be hard to implement properly because of the numerous ways in which a template can be set. A naive implementation is more doable, though we are not notified when the ItemTemplate property changes
====
Reason for marking this Declined: Too little information, too old item (5.5 years) with too litle votes.

The request is related to the method AddItemByPath - To build the whole hierarchy not only to add the string after last separator.

Too specific requirement that could be implemented as application logic.