There may not be an objective God’s-eye-view point of reference, but, just as in real life, there is the place where you are. In this case, it’s either the object that the user is viewing the Flow or Graph from, or that has been turned into a widget.
Here’s how your graph could be displayed from the point of view of each object. I don’t know if any of these fit the technical definition of a “tree” you’re using, but the point is that they show a hierarchy. I started with the idea of the Flow view (where you can see both parents and children of the object you’re on), expanded it beyond one level, and applied the logic of the widget view:
As in the widget view, the convergence problem is solved by allowing a single object to appear more than once. In the second and third examples, a “sibling” object disappears, but that’s already how the Flow view works, so that shouldn’t be a problem. It’s only a problem if you always want to be able to see the whole web, but as you’ve rightly pointed out, a heirarchical view is ill-suited for that. And that’s not the purpose here. The current Graph can already show you everything, and I don’t think anyone is saying that that needs to be done away with. What people seem to be asking for (what I’m asking for, anyway) is the additional option of a more narrowed view - a filter, if you like - for any single object and its direct relations, out to multiple levels. The widget view is a great start, but there could be better.
For good measure, I’ve made a variation of your example to show how looping can be addressed:
The widget view constrains the display of loops by requiring the user to expand them manually one level at a time. Something similar could apply here, where the dotted lines represent places where the user can choose to expand if they want:
Also, I’m not sure if I conveyed it well, but I intended for repetitions of the primary object to be denoted with a sort of half-strength visual bolding.
I appreciate that you linked to that related feature request. I support it and added my two cents, though you’d bowed out of the thread by that point so I don’t know if you saw it.
So when it comes down to it, are your objections actually about function, or are they really about philosophy? The posts of yours I’ve seen here and in the FR thread seem like they’re about the former, with articulations of network-theory reasons why you think hierarchical displays wouldn’t be workable in AT. But saying that a desire for hierarchy is “brainwashing” and not “adult” thinking makes me think the technical arguments are secondary to your real objection that those of us who find hierarchy useful and want to create it in AT are simply wrongheaded. I want to engage in good faith here, but I’d like to know that my interlocutors are doing the same. I understand that AT is meant to transcend hierarchy, and that’s awesome for those who want to use it in that way! But my needs are actually hierarchical (charting task dependencies), and I’ve been successfully using AT as such for months, to better effect than any other app I’ve tried. To use the physics analogy again, relativity was liberating, but it didn’t make Newtonian physics obsolete. I see no reason why having “Newtonian” tools available within the “Einsteinian” framework of AT would be wrong.