Tasks and some other objects currently have relationships like "Related Revisions", "Subtasks", "Parent Tasks", etc. These relationships are somewhat general but not fully modular, and extension code can not add new types of relationships (at least, probably not in a satisfactory way) today.

Previously, in T10034, I generally declined to directly implement support for certain new relationships, but left the door open to pursuing this eventually (see T8345#187639 in particular). At the time, the use cases were fairly weak, and I suspected that work connected to T10034 likely resolved or improved many of the problems users faced (this seems to have been at least mostly true in practice, since I'd subjectively claim that this general issue quieted down afterwards).

Some new use cases have arisen recently which provide stronger justifications for finishing this work and properly modularizing these relationships. In particular:

• See PHI1442, which would like to relate tasks in a particular structured way to satisfy regulatory requirements.
• See PHI1261, which discussed the idea of an "Addendum" relationship, where a parent document can be frozen for regulatory reasons, but if there's a need to continue discussion about things it could occur in a related addendum task.

More narrowly:

• See PHI1422, which would like more structured configuration of relationships, particularly a way to specify that tasks of subtype X may only have relation R to tasks of subtypes Y or Z.
• See PHI1404, which raises some usability issues with the relationship dialog.
• See T3577, which is a general issue with how these relationships work.
• See T3287, which is a broad request for control over how relationships are affected by merge operations.
• See T7805, which proposes some improvements to the selector dialog.