It seems to me that the first and third problems are almost the same – you want to restrict where nodes can be dragged, because each node is designed to be in a particular parallelogram-shaped area.
This can be done by setting Node.dragComputation, https://gojs.net/latest/api/symbols/Part.html#dragComputation , or by overriding DraggingTool.computeMove, https://gojs.net/latest/api/symbols/DraggingTool.html#computeMove and making sure the node does not leave its proper three-sided parallelogram area. But maybe you do not need to do this work…
Normally the order of data in the Model.nodeDataArray should not matter. In the case of using a TreeLayout, the programmer can control the relative ordering of the immediate children of a node by setting TreeLayout.sorting and TreeLayout.comparer. This is complicated in FishboneLayout because it uses go.TreeLayout.AlignmentBusBranching
.
https://gojs.net/latest/api/symbols/TreeLayout.html#comparer
But maybe you are wanting to change that ordering when the user drags outside of the natural parallelogram? You can do that by adding your own data property that specifies the order of the children within the set of siblings, and sorting on that property. I suggest that you could do that when the user finishes dragging the node, in a “SelectionMoved” DiagramEvent listener. You would need to figure out the new ordering of siblings based on where the node was dropped.
https://gojs.net/latest/intro/events.html#SelectionMoved
A good thing about doing this ordering is that it also can avoid the need for implementing what I suggested above for the first and third problems. You would not care where they dragged a node, because the end position only signifies the desired relative ordering, which in turn would cause another layout to be performed.