Object hierarchy and relation connection are two different things. (While to me, every relation is an object and every object can become relation). What I am requesting is richer relation display… but only with simple relation variation; not how object should relate to other object or multiple objects (that’s beyond the scope of this request)…
Hierarchy can expand to the end of the world. What I would suggest is to limit the extended context to 1/2, that way we could insert the immediate context to as a second level naming of object (as what I would name as sub-object). If it is direct relation, it would display as a near concept object, no further display is needed. But if it is an usage / application of concept in a different context that we still need to reference the upper hierarchy (Like 3-5+ hierarchy / depth away), then we don’t need to go down the rabbit hole, just a mention of relevant context object will do.
In high level thinking, every definition can be redefined to derive a different approach (like Anytype terminology). Therefore, there is a need to reference the context of the concept.
For example, in the context of psychology, needs in Maslow and needs in Freud are different… Looking at concepts, it is still simpler… but if we apply on people (and even only 2 people’s different reactions in 2 different incidents each), the graph already look pretty messy, especially if we link up the whole tree of concepts. I would probably isolate concept graph with people graph, by utilising local graph, filter and/or controlling depth of link level (like in Obsidian local graph), or even set graph.
Limiting the cognitive load / information is useful. This is what we do when we think too… we can’t go over the board. Our brain can’t attend to too much information at the same time. Butterfly effect is a thing but not necessary for all situations. Do some compartmentalisation - it helps.
This would bring a different issue, how can we distinguish context and concept? Upon object creation we could set different object type. This is where rich core taxonomy could take place, but the expected behaviour for different object type relating differently with another type can be ill-defined across different fields and within object type.
Fix hierarchy (as what taxonomy would mean?) make sense in a static form, but not dynamic… Concept’s hierarchy might be more fixated in physics but not necessary so in other fields. Relations are dynamic in many cases, depending on the viewing angle. E.g. Author is the owner object of a book… but book’s properties contains author; both can be sub-object to another. The hierarchy making process should depend on users’ creation. Local graph view feature will assist hierarchy making, if we add more relation display we. Parent-child-sibling relations (as outlinks and backlinks) should also demonstrate a lot.
Currently what I do is have a relation called “Core” to display it being the upper hierarchy / theme / category. Not so neat, but acceptable and observable.
Note-taking can be super meta and abstract, but it is really the basic for high level thinking… This shows how much we humans are capable of. We could simplify things and enrich the new simple and then continue to develop.
Hope Anytype team will invest in this type of thing… but we probably should not make it hard for them to make it happen too… is for the sake of both.
Sorry, but not sorry, we are nerds 
) and I can see the potential value and benefit of being able to represent the ‘anti-relationship’ of things… but I don’t know what the most elegant implementation of that would be, off the top of my head…