Teaching trees and debugging them

I meant to post this in the pain points thread, but the size of this post got a bit out of hand, so I posted it as a seperate thread.

Trees are awseome. But unfortunately still hard to explain, and you can still find some wonky behaviour in GH related to datatrees. My experience is that new users quite quickly get the hang of it once they learn that a tree is in fact not a tree but in the first place set of lists, where the path shows how the pieces of data used to be grouped.

Branch Count checking A component has multiple tree inputs, but has different amount of branches, each having branch count > 2. (While I understand the logic of combining multiple trees, I've not once encounted once that combining a component with e.g. an input of 2 branches and an input of 4 branches to give any kind of sensible output.

Desired behaviour: If a component has branches (each being > 2 path count), the component should throw a warning. ("Strict branches behaviour?). For example: take an offset component, with 6 branches of curves and 5 branches of offsets. It is extremely likely that this is the result of an error earlier in the definition. This works however without a problem - the last branch is repeated again, and it's later on quite hard to discover something went wrong.
Checking branch Count The most important numeric is the amount of branches, and the amount of items in the tree. It's desired that the hovers show the amount of data and the amount of branches.

Desired behaviour
Trees with paths of different rank Trees that contain {0;0} and {0} and {0;0;1} is usually a sign of trouble of not well merged trees, faulty C# components, or just nasty coding habits.
Trim as undo graft instead of flatten Having the trim in the context menu would provide an easy way to undo a graft. Right now the easiest way for many people is to flatten it, and then start all over again - while just getting rid of the last index keeps the underlying history and makes it easier to write reuseable pieces of code when you prepend datatrees to it.
Component to get branch by index, not by path Would be great. Suppose you have a grid of points, grouped by row. It would help to show: "look, this is in the first path, it's called {0;0;1}, it's got 10 points, these points are the first row".

Analogue to using list item to show what is the first point, second point, and so on.

Semantic path names (maybe far fetched) But what if we can add a short name of each method that was executed to the path list, so it can show:

{Slider 0; Series 0; Point 0}{Slider 0; Series 0; Point 1}

{Slider 0; Series 0; Point 2}

{Slider 0; Series 0; Point 3}

{Slider 0; Series 1; Point 0}

{Slider 0; Series 1; Point 1}

{Slider 0; Series 1; Point 2}

{Slider 0; Series 1; Point 3}

Make the input/data matching inside components explicit Can we make it even more obvious that a component is not a black box that's executed once, but in fact an iteration machine that tries to make sense of the inputs that's fed to this box?

Show data combination. How data input A relates to data input B and data input C, is currently very implict and is just plain hard to learn., and required the ability to be able to relate the output back to the input. If we can textually or even graphically show what data matching occured inside a component, it would greatly help the understanding (and debugging) of "what's going on here in this component"

A verbose explanation of the data matching in component A

Iteration one:     - Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)    - Motion:   We take the data item from Branch 0, Position 0: (Vector 0,0,0)



Iteration two: 

    - Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)

    - Motion:   We take the data item from Branch 0, Position 1: (Vector 10,0,0)



Iteration three: 

    - Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)

    - Motion:   We take the data item from Branch 0, Position 1: (Vector 20,0,0)

etc.

A verbose explanation of the data matching in component B

Iteration one:     - Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)     - Motion:   We take the data item from Branch 0, Position 0: (Vector 0,0,0)



..      



Iteration seven: 

    - Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)

    - Motion:   We take the data item from Branch 7, Position 0: (Vector 0,70,0)



..



Iteration 27: 

    - Geometry: We take the data item from Branch 0, Position 7: (Point 80,0,0) 

    - Motion:   We take the data item from Branch 2, Position 0: (Vector 0,20,0)