Too many TreeViewItems are created internally when using virtualization. This causes the tree to consume large amount of space when performing virtualization intensive tasks like CollapseAll or ExpandAll.

The XAML team recently reviewed this issue and will not be addressing it.
On ExpandALL / CollapseALL virtualization creates / recycles / reuses containers - RadTreeViewItems. You cannot be sure when the GarbageCollector will free up the currently unused containers.
Also after even number of invocations (ExpandAll + CollapseAll), the containers that are not freed up from memory is not increasing - it is constant which means there is no memory leak to worry for.

When two equal objects are used in the source collection, the first is always selected when you try to select the others.

Workaround when TreeView is not databound.

Instead of adding objects directly in the TreeView's Items Collection, add RadTreeViewItems.
For Example, instead of
 treeView.Items.Add(1), 
treeView.Items.Add(2)

do

 treeView.Items.Add(new RadTreeViewItem(){Header = 1}, 
 treeView.Items.Add(new RadTreeViewItem(){Header = 2}

Workaround when TreeView is databound.

For example , if we databind the treeview to collection of DataItems and some dataitem is located in multiple places in the source collection.
Solution => Wrap the DataItem class in new class - DataItemWrapper. It can hold the underlying DataItem, add additional property  (for exampel ID) and override the Equals and GetHashCode methods.
This way different DataItemWrapper objects can hold equal DataItem objects. In such way if you bind the treeview to collection of DataItemWrappers the selection will be successful.

DECLINED:
The XAML team recently reviewed this bug  and won't be adressing it in future. It can be actually considered as feature request because selection should have notion for selected containers.
Unfortunately, the initial code design of the RadTreeView does not have such notion and the complexity of adding such feature now is very big.

When using binding to CheckState property and TriStateMode is enabled the checking of parent (its business object) does not affect unrealized childrens' CheckState, because the bindings have greater priority than the TriState logic. Same in the other direction - checking the child has no effect over the parent.

Marking this as Declined.
TriState Mode is supported in XAML-defined or code behind defined trees with direct creation of 3Viewitems. 
In DataBound scenarios, 3-State should be created by the user with ViewModels as described in this help article.

http://www.telerik.com/help/wpf/radtreeview-howto-tri-state-mvvm.html

SelectedItems collection not updated when items are removed

When TreeView is placed inside floating VS ToolWindow and item is selected the visual state remains unchanged after focus leaves the TreeView.

When using binding to check state and dynamically adding subitem to a praticular items, the parent items check state is incorrectly set to Off (from ON) although the child item state is also On.

Marking this Declined. Binding to CheckState is not supported in MVVM scenarios. Please use the approach described here =>
http://www.telerik.com/help/wpf/radtreeview-howto-tri-state-mvvm.html

a) Using WCF RIA Services
b) Using QueryableDomainServiceCollectionView
c) Using TreeView with above two
d) Including LoadOnDemand
e) Using "Prepared Item"

When value types are inserted in the Items collection of RadTreeView and root values are duplicated in the children a StackOverflowException is raised after a call to ExpandAll.

The XAML has recently reviewed the status of this issue and won't be addressing it in future releases.
This is a design limitation - RadTreeView does not support duplication of value types in its Items / ItemsSource collections. 
This potentially can cause troubles with virtualization / selection / expandALL features.

When the RadTreeView is virtualizaed, the images are  not shown. This works when the tree is bound to collection of objects and the DefaultImageSource is bound.

Reason for deletion:
The workaround is easy - just bind the DefaultImageSrc, ExpandedImageSrc to string properties from the ViewModel.
Also, a possible fix would slow down the virtualization process in the RadTreeView.

Binding to IsChecked property doesn't work in TwoWay mode (ConvertBack doesn't work).

Declined.
IsChecked / CheckState are supported only in xaml-defined RadTreeViews. In databinding scenarios use the approach described here =>
http://www.telerik.com/help/wpf/radtreeview-howto-tri-state-mvvm.html

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.

When a large number of items are selected through extended selection (with a lot of items on the first level of the RadTreeView) the selection does not work correctly. 

Ability to have both static and bound RadTreeViewItems or different hierarchy levels.

Reason for decline: There is no proper way this to be implemented.
 This would require huge refactoring of the DragDrop, Styling, Editing, Virtualization logic. 
Complexity of such task  is close to writing a new control from scratch.

Items are lost after reexpanding when TreeView is Virutalized and items are set in XAML.
Currently the TreeView does not support virtualization when using XAML items.

Reason for Decline: Virtualization is not supported in non-databound treeviews.

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).

DataTriggers that apply DefaultImageSrc, ExpandedImageSrc don't work when the TreeView is virtualized.
Reason for deletion:
The workaround is easy - just bind the DefaultImageSrc, ExpandedImageSrc to string properties from the ViewModel.
Also, a possible fix would slow down the virtualization process in the RadTreeView.

The CheckedItems  collection is not cleared when ItemsSource is changed.

Please consider CheckedItems as not supported collection in RadTreeView. In DataBinding scenarios , use the approach described in the following article:
http://docs.telerik.com/devtools/wpf/controls/radtreeview/how-to/howto-tri-state-mvvm.html 
This way you will be able to create CheckedItems property in your ViewModels.

The XAML team has recently reviewed this issue and will not be addressing it as at this time the team is focusing on the bugs impacting the highest number of developers. If you have encountered this issue and it is blocking for your work please contact us through the support ticketing system with details on your setup and a reference to this item.

When the ScrollViewer of a virtualized TreeView is visualized the bindings of the TreeViewItem are broken.

We are closing this one because of duplication with the following item => http://feedback.telerik.com/Project/143/Feedback/Details/112754-treeview-bindingexpressionerror-occurs-in-situations-when-the-tree-is-virtualiz 

Ability to temporary view particular element as root item. Functionality have to be similar to "View this as root" in the Solution Navigator window in Productivity Power Tools for Visual Studio.

This is too custom requirement that can be implemented as application logic. 
Setting fildetered itemssource and preserving the current itemssource could be a possible solution.

We have a RadTreeView. There is no horizontal scrollbar.
We edit a node's header to a longer string and a horizontal scrollbar appears.
If we edit again the node's header to a shorter string, the horizontal scrollbar remains even it isn't needed anymore.

UPDATE:
There is a similar problem with the height of a RadTreeViewItem.
If we edit the RadTreeViewItem's content to become at least of two lines - the height of the item is increased, which is expected.
But if we re-edit this item's content to be on one line only - the height of the item remains larger, which is incorrect.
Please note, that this issue is observed ONLY on sub-items not on the parent nodes.

This seems not reproducible  with R3 2016 version of RadTreeView.
Please open a new support ticket with details regarding this issue if you encounter it.