I'm the reporter of this bug. Just to make the explanation a bit clear, here's an explanation of the problem which motivates the report.

Here's a sketch of the tree view (add "https://" below):
drive.google.com/file/d/1oaC32nGy98HlA02UyFuEuwt_MjzwjZbH/view?usp=sharing

This is a TreeView where each element has an identifier (A, B, C, D, ...), and each element has an index, starting from 0 and incrementing a unit each for each subsequent element, just like TreeView API does.

Let's say we drag the element X and drop it somewhere else. As soon as we do that, the "itemIndexChanged" event fires and executes with the index of the element dragged, as well as the index of the element dropped.

However, because both parameters are indices, and not the element ID, we can never know what element was dragged (X in this case), because that position is no longer valid, since the state of the Tree has changed due to the move operation.

Apart from that, if we drag and drop the element X onto B, X will be placed as a child of element B and the "itemIndexChanged" callback will have the following parameters:

As the draggedIndex, the index of element X (which is n), and as the dropped element index 1.

However, if we drag and drop element X again, but this time, right below element B, the parameters will still be n and 1.

This poses a problem, because it's impossible to determine what element was dragged, as well as what operation was performed, since the signature parameters are exactly the same when dropping an element onto another one, or between two elements.

Hope that makes sense! This could all be easily solved if the "itemIndexChanged" event filled the callback parameters with the unique ID of TreeViewData structure, instead of the indices.