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

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

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

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

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.

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.

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.

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. 

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 

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

Improve the synchronization between the TreeView.IsOptionElementsEnabled with the TreeViewItem.OptionType property. In a scenario where the TreeViewItem.OptionType property is databound, changing the TreeView.IsOptionElementsEnabled property doesn't respect the databound values of the TreeViewItem.OptionType.
===
Reason for deletion: These  proeprties are marked obsolete.

The TreeViewPanel doesn't display the TreeViewItems when the TreeView ItemsPresenter ControlTemplate element is wrapped in a Border or Grid control.

Declined.

Changing the default control template of our controls is risky, every template part has its purpose and usually it is used in code behind. 
We cannot support such template changes to not reflect the main features such as virtualization,scrolling, fast performance.