Sorry, I guess I wasn’t clear 
When I presented the two examples, I was just trying to imagine that a user could have developed a space with similar complexity and included self-relation for one or more of the lower levels.
In your example, you wrote:
This is based on an implicit assumption that Program-as-parent relation takes priority over Portfolio-as-parent relation. When looking at the hierarchy diagram, that is a reasonable deduction.
However, taking the Usability Testing as an example (and assuming that Attempt is self-related) I am struggling to see how your logic could work reliably.
Based on your ‘rules’:
- Build each database’s nested structure
- Try to map root items
If a hierarchical list is to display all databases, I can’t see how Fibery can determine whether an Attempt should be prioritised to be mapped under a Participant or a Task?
I guess the answer is that the user is required to choose a single ‘hierarchical path’ (either Test → Participant → Attempt or Test → Task → Attempt) and that resolves it. Maybe that’s OK.
But this is a constraint that is acceptable/valid for one-to-many relations.
I am aware though that any changes made to support self-relations need to be compatible with (future) support of many-to-many relations:
Implementing specific logic for self-relations might hinder that future development.
To be honest, I totally want to see self-relations at lower levels, so I hope the dev team can figure it out without painting themselves into a corner.