The compelling case that made me think through how to do it right, rather than avoid it on a case-by-case basis, was in GUI windowing. A window contains a list of its children, and the child points back to its parent. Meanwhile, I was working on asynchronous programming concepts. A "weak reference" can't work if the order of destruction is not defined. This concerned writing the functions that do the acting on input! Basically, WNDPROC in Windows, or closures binding an object and method to call queued to a server thread. When a method is being executed, the object cannot be destroyed. But between, it is fair game, and pending things will fail (guaranteed) as the graph of objects is being taken apart. Basically, think of your query idea as "reference" without using the problematic pointer. I separated the concepts of "reference" from "ownership". Without prompt destruction like I like and depend on in C++, the latter concept might be better described as "dependency".

I agree that most relationships are not explicit because objects act on input rather than being known by each other. But I have small knots of typically 2 objects in this relationship, and the ability to separate the lookup from the use in time due to asynchronous calling.

—John