Fun question. I go over a couple things and I hope I'm clear enough to answer your question. I'm not 100% sure I understand it, but I'll give it a try.
The bottom line: arrow direction matters. I think this is the root of your final question. When you talk about "the results are", Diane knows Julia but in graph-terms, Julia does not know Diane because the arrow points left to right. BUT, in your MERGE statement, you have no such bias. This is significant. I'm one who wishes Neo would be overly explicit, but I understand their convenience argument. If we have a MERGE (a)-[r]-(b), we really have two statements: (a)-[r]->(b) AND (a)<-[r]-(b) and that reality lives in a strange state. The direction of the relationship in a graph is a very important part of graph theory. "a" and "b" have, in the real world, explicit relationships. A path algorithm, for example, must have a clear means to determine if there is a path or not. So when you have say (a)--(b)-->(c), there IS a path from "a" to "c" but NOT from "c" to "a". And the portion of the path that's less explicit ("a" to "b"), becomes explicit in the algorithm but remains in that non-explicit state. This can be a source of bugs in algorithm creation, for example. All this does become somewhat clearer if/when you use an adjacency matrix to show your graph data - where the direction of the "arrow" really begins to make mathematical sense. In Neo's compromise for convenience, I hope that there's a "1" in a-b and b-a. But that's not always clear. But I build my graph based on that assumption. If that's what you mean by "left" and "right", I'd look more toward "ab" and "ba" and how those are defined in your models - and enforce that!
To stress this point, in your example, Julia following Diane is very clear as Diana does NOT follow Julia. So with all this in mind, it should be clear that there's a "1" in the juncture between Julia to Diane and a "0" in the reverse. So again, that's not left/right, rather ab/ba.
Finally and why I labor on here is because there's a danger in the query "MATCH (P1)-[R]-(P2)" that exemplifies why I struggle with the convenience of allowing a sort-of, non-directional graph facility. This query will return both the directional and non-directional results. If that's in the midst of a question that depends on the direction, it will return invalid assumptions - such as Diane possibly following Julia. And because that's allowed in Neo, there's coupling needed between you knowing the data and the data telling what you need to know. Sure, if you need direction, you can ensure that by your Cypher, but that has obvious risks.
Not so important if it's about movies, but if it's a query about the CORONA virus, asking billions of nodes questions, that could be significant 
HTH.
Sorry for the absence. Took a nasty fall that made typing impossible so, have been recouping. I'm better enough
I think this level of question needs to move away from the "tool" (Neo) and into the math or graph theory. Love the question about "who owns" the "direction" whose answer is "both" and/or neither. Let me explain.
A "graph" is visual to humans starting with the now famous bridge problem. But the math of graph theory is not a visual rather than a model and a means to ask questions of the nodes and relationships. The best way to see how this looks for the "ownership" understanding, is to see a graph as a matrix.
Let's keep it super simple and imagine a 2 node graph. In this case, we can add a relationship...but remember, a graph G can have nodes and NO relationships. So I can't inset a table it seems but imagine my matrix[a,b] with cells [a,a],[a,b],[b,a],[b,b]. These are the four "points of view" of the two nodes. I saw POV because 'a' can look at itself and at 'b'. And 'b' can look at itself and at 'a'. NOTE: while 'a' and 'b' can ONLY see themselves from a single POV, they can see each other from two perspectives a->b and b->a. I'm not addressing direction yet, just POV. Simple graph theory is rather basic but this elegance of design enables very complex ideas. But for now, let's stick to the basics.
Assuming (arbitrary rule I'm saying here because it's consistent with how Neo is designed but NOT how graph theory limits the math) that any POV in our graph G can have either a "0" or a "1" as the value. The matrix then, can range from all zeros to all ones. Each cell that has a "1" in it moves from the column label to the row label (you could do either direction, just be consistent). And that "1" is THE DIRECTION.
So you can see how ownership of the direction is intimate with the matrix that represents it. This also addresses how you can NOT have a relationship to a relationship (i.e., when limited by this design concept of using a matrix.
So, hopefully this is helpful. I like how you are exploring graph issues like a graph's dimensionality. I do know of tons of work in graph DB design around adding to this most elegant matrix foundation. But most of these efforts, IMHO, are lazy and miss out on what I think is more the "next step". Instead of adding dimensions to the model, I'd say we should spend way more time addressing matrix multiplication, dot product, vector involvement, etc. This you can see in the graph algorithm work being done at Neo and other places in the graphista community. This is a huge need in the ML and AI work where graphs are going to become so key. Once we have that in place and performant, then the ideas of exploring multi-dimensions beyond what all that will uncover, will be useful to explore (if needed which I debate BTW).
Thanks and HTH.
NODES 2022, Neo4j Online Education Summit
All the sessions of the conference are now available online
