There is already a Edit blocking tasks link for the relationship between tasks. So the issue is what to do with the related tasks.

What can we do in the current state?

As a workaround, you can write the other tasks in the description:

See also: Ta Tb Tc Td

Automatically, Phabricator will then create a comment in the quoted tasks:

<username> mentioned this in T<id>: <Task title>.Via <source> · <Date>

Technical overview

In Phabricator vocabulary, what you're asking for is an edge. It would here be a same level edge, the blocking relationship using hierarchic edges (this is technically a field + - =).

An UI similar to blocking tasks could be provided and populates new edges.

Cost/benefit

We would create a deviation of our Phabricator codebase compared to the upstream product. This deviation would be costly to maintain, as we'll have to edit the existing classes code, and so continually rebase it against master.

I'm not confident this feature would be accepted upstream, as one of the goal of Phabricator is to keep things as simple as possible and avoid a clogged input form Bugzilla-like.

The benefit would be rather low: to add a clearer metadata, as similar tasks would be in the properties, and not the description. We'd also automate the process of adding that information in other tasks but then would lack the possibility to be flexible and define non bilateral ''see also'' relationships.

Are there dedicated fields in other tools (Trello, Mingle etc) that allow expressing a relation that is not blocked-by/depends-on?
If so, how does structured data (in contrast to having such info as freeform text in the description) help you when it comes to supporting your workflows? (For example, Bugzilla had a "See Also" field but did anybody search for values in that dedicated field via Bugzilla's advanced search?)

No opinion on the task, but:

but did anybody search for values in that dedicated field via Bugzilla's advanced search?)

Yes.

I frequently consulted bugzilla's lists of "See also".
I now find myself having to scroll through the comments of every phabricator task, looking for mentioned this in lines, as well as Tnumbers within comments.

E.g. I would previously have linked T75209 and T1188 to each other via the SeeAlso section. Today I wanted to find them both, and I had mentioned one in a comment at the other, a few weeks ago, and so I knew that I could find the link to the alternative somewhere within either of them, if I looked hard enough.
To get them clearly inter-linked, I had to edit both tasks, and just stick it in at the bottom of the description (now done). (Now the problem is: anyone who gets an email update for that, won't have any context for what was added/changed in the description. cf. T75851: Email notification for "edited the task description" does not contain the actual content changes (diff) nor a link)

On the other hand...
I do understand that - whilst is more labour-intensive and less consistent to manually add the link at both tasks - it does give us the chance to give additional context for the SeeAlso(s), and also to link to onwiki pages, both of which were lacking in the automated internal-and-link-only bugzilla system.
I'm not sure if that trade-off is worth it though. I'm currently leaning slightly towards encouraging the creation of a SeeAlso feature, upstream.

and so I knew that I could find the link to the alternative somewhere within either of them, if I looked hard enough.

That's why I can only encourage folks to edit task descriptions to add "See Also: link" to them. Bugzilla did not allow improving the initial comment of a task to act like an updated summary - that can be something pretty useful that we should embrace (at least it's one of the popular complaints about Bugzilla).

Still the last comment does not make me see a reason why a "See Also" link to another task should be in a dedicated (structured data) field.
Whether somebody forgets to add a link to a "See Also" field in BZ or to the initial task desc in Phab only makes a difference if someone is actively after searching for an already known value in that specific field (or for "field is not empty" if the search of the tool allows that), and that does not seem to have been the case for the given example as both task IDs were not known. :)

Proposal at T76922 which might solve this, sufficiently. (?)

In T76101#822965, @Quiddity wrote:

Proposal at T76922 which might solve this, sufficiently. (?)

I don't see how it would.

tgr, andre wants examples of actual use-cases (ideally something convincing enough to make upstream excited about working on this feature, along with the pile of other requests we've submitted). I'm too distracted with other tasks to think of anything solid. I put up the alternative quick-fix proposal because it might be better than nothing. But I'm open to anything!

I just don't see how that's an alternative. You can already write "see also" notes in the bug description. Prettying up the migrated ones would be nice but it's not what this bug about, which is handling them in a structured way.

The main use case I guess is convenience - this is a two-way relationship, so manually you would have to edit the bug, go to the other one, edit that too. That also creates useless notifications as Phabricator does not include any specifics in the email when you edit a bug description.

I don't want to report this task upstream, because I still disagree with it. I don't think it makes any sense to keep discussing among ourselves here, when this discussion should happen upstream with the maintainers. If someone wants to propose this task upstream, please do so. I propose to decline this task here.

Maybe we should take a step back and state the problem instead of proposing solutions. Do we agree that grouping related tasks is harder than it should be? (Currently we handle large groups by tracking tasks or tracking projects, but both are too much effort for a small group, and even for large ones they have shortcomings - blockers are poorly supported on the interface and in searching, and project creation is a slow and disempowering process, but a more liberal process would probably lead to a project proliferation that the simplistic project selection interface would not handle well.)

I think the possibility to associate tasks to multiple projects and blocking relationships are enough to organize tasks. Adding a "See also" adds another element in the UI for all tasks, when only a tiny percentage will actually need it.

When I want a see also, I type "see also" in the description. Many times that relation is not bidirectional, and the inverted "see also" makes less sense.

https://secure.phabricator.com/T8345 is "Add related tasks" . I used See also a lot in all project management tools I've worked with.
I can see the benefit of being required to add a comment, or the description field, to describe the relationship between them. But once I've written or read the description once, I dont need to read it again, and definitely dont want to have to read through all comments to find it.

So, I would appreciate an automated collection of 'Related objects', for things mentioned in comments, being shown in the header so I can quickly jump around.
I am occasionally using blocking relationships, incorrectly, instead of adding related task to the description because the blocked task is a higher priority , but in reality not quite a blocker.

On the UI, I'm envisaging these related tasks as a column on the right, *beside* the description. Maybe only object identifiers would be visible due to UI constraints, but I could hover over them to see the description.

It's trivially easy to implement mentions as links in the details section of a task. The only part I'm having trouble with is how to label them? Naming is hard.

Anyone have some bright ideas? This bike shed is in need of a paint job.

/me goes looking for a different yak to shave.

Stackoverflow simply calls that section of the sidebar "Linked".

A dedicated "Related Objects > Mentions" section below the task description exists since the 2016-11-16 update.

Is that sufficient?

In T76101#2802934, @Aklapper wrote:

Is that sufficient?

Personally I like it a lot more than the Bugzilla approach.

Now if only someone fixed T687: Convert Bugzilla's "Bug NNNNN" links to "TNNNNN" links in Phabricator :)

In T76101#2802934, @Aklapper wrote:

A dedicated "Related Objects > Mentions" section below the task description exists since the 2016-11-16 update.

Is that sufficient?

Huzzah! This is great. :)
My only request, is to make both 'tabs' in the "Related Objects" section, display at once. I wouldn't have noticed the 'Mentions' tab, if I hadn't stumbled across them in a task that didn't have a 'Task Graph'. (Perhaps you could relay that suggestion upstream, along with any other feedback that arrives here?)

In T76101#2803955, @Quiddity wrote:

I wouldn't have noticed the 'Mentions' tab, if I hadn't stumbled across them in a task that didn't have a 'Task Graph'.

Same here. Not sure it needs to be visible all the time, but it could definitely use some UI tweaking.