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

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.

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.

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.

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.

Setting the IsChecked via binding causes synchronization issue with CheckState during initial container creation.

Declined.

IsChecked and CheckState are not supported in binding scenarios. In databinding scenarios use the approach described here.
http://www.telerik.com/help/wpf/radtreeview-howto-tri-state-mvvm.html

When the FlowDirection is RightToLeft, the vertical lines of the control aren't properly aligned.

The issue is not reproducible with R3 2016 Release.