I think that TreeView incorrectly handles the case of a drop beneath a node that is expanded.
When a node (with or without children) is _not_ expanded, then dropping directly beneath (meaning lower down on the page) that node indicates that the node should be made the next sibling of the node.
------ <- Drop indicator means that dropping here will cause the dropped node to be the next sibling of B, which makes sense.
This case makes perfect sense.
However, when the node is expanded, the drop indicator doesn't change it's behavior, and I think it should.
------ <--- Dropping here will cause the dropped node to be the next sibling of B, but this is not visually where it will appear in the tree.
<--- This is where the node will appear after drop.
This is counter-intuitive to most people. People think that dropping between B and B.1 would make the dropped item to become a child of B and a prior sibling of B.1. But instead, it has the same effect as if the B node wasn't expanded and adds the new dropped node as the next sibling of B. Note that in this case, the newly dropped node doesn't show up where it was dropped. When a node doesn't appear in the tree where it was dropped, people assume that that's a bug.
To see the issue, go here:
In the "RadTreeView1" treeview, try to drag the "Deleted Items" item to be the last item in the list (but not a child of "Search Folders"). If you drag toward the bottom of the tree, after you drag down past "Unread Mail", you see the drop indicator that shows that you can drop to make it be the next sibling of "Unread Mail". If you keep dragging down, you _don't_ see an indicator that you can drop to make the next sibling of "Search Folders".
However, if you drag between "Search Folders" and "Form Follow Up", then you _will_ see an indicator that shows that the item will be made the next sibling of "Search Folders". And if you drop there, it will indeed be made the next sibling of "Search Folders", but of course it will appear at the bottom of the tree (not where you dropped it).
The kendo TreeView has the same behavior as the RadTreeView. However, I have found some TreeViews that handle it in the way I would prefer. See http://mbraak.github.io/jqTree/ for an example.