What decisions do you make based on the number of duplicates merged into a task?

It helps to judge the importance of the task. If I see a task that has >10 blockers, I usually see immediately that it is some kind of umbrella task. If I see >10 merged-in duplicates, I see that the missing features probably impact a lot of people, maybe in a different way.

My concern is subscriber counts and tokens already provide reasonable insight into feature impact. When duplicates merge in, users are merged in as well. Adding a third thing to gain insight from likely has diminishing returns at the cost of visual clutter over the task information itself.

I might be wrong, but seems like you could build this as an extension today for Maniphest as a CustomField?

T8345 is still likely how we'd provide this information, as people want to know all edge relationships in general.

In T9390#136438, @chad wrote:

My concern is subscriber counts and tokens already provide reasonable insight into feature impact. When duplicates merge in, users are merged in as well. Adding a third thing to gain insight from likely has diminishing returns at the cost of visual clutter over the task information itself.

That is certainly true for big installs with lots of users. It is more practical with a small user base and long-lived tasks, where you basically know all of the subscribers. I return to the task and see "oh, this one has gathered so many duplicates in the meantime"

I might be wrong, but seems like you could build this as an extension today for Maniphest as a CustomField?

Any pointers for that?

1 on this from me, but I agree that this is a duplicate of T8345.