Related: T4768: Phabricator silently overwrites concurrent changes (no conflict detection)

Making these appear less often / never is likely a better solution anyways. We could also make the language less scary.

I don't think we can make these appear any less often -- what do you suggest we do instead when you try to add projects that are already on the object?

qgil suggested T4768, which if solved somehow, would reduce at least the number of times someone might see this. We could also instead of going hog-wild just identify the 10 most common or likely collisions (Maniphest?) and that's probably reducing 90% of cases.

This is the solution to T4768. Solving T4768 will make some version of this happen much more often.

What is "This" in your statement, I'm not sure I follow?

To me this task is asking for better language on conflicts, where T4768 is asking to auto-resolve or pre-warn about them. If we auto-resolve or warn before submit, then this dialog on appears less often?

Specifically, this dialog solves three problems related to concurrent and mistaken edits:

1. Long ago, before transactions were formalized, we posted empty comments in this situation. This was just a (complicated) bug which was mostly fixed in a general way by moving to transactions, there's some historical discussion in tasks like T1782 and T2030.
2. Users would add duplicate CCs and projects (either by accident, or by racing with another user) including a comment describing the change. For example, they'd add @alincoln and make a comment like "Do you know what's up with this?". We'd drop the no-op CC and post the message, which would no longer make sense with context missing. This was generally confusing. That's why we have this dialog:

1. Users would add duplicate CCs and projects (either by accident, or by racing with another user), with no comment, and we'd eat the entire transaction and do nothing. This was generally confusing, which is why we have the "no effect, with no comment" dialog.

I'm not totally sure about relatively prevalence in the wild of the two cases, but I think mistakes and race conditions are both encountered frequently. Removing this dialog would reintroduce problems (2) and (3) above in both cases.

This control is also already race-resistant, some discussion in T6205.

"This" is "a dialog which notifies you of a mistake or race". In T4768, we do not detect races and just overwrite concurrent changes ("last save wins"). Fixing T4768 will involve more "there is a conflict" dialogs -- even if they are combined with a nonblocking warning, we can not guarantee we will be able to show the user the warning before they submit the form because of the nature of race conditions.

Note that in the dialog above, the string is also wrong and untranslatable, and we need to go break out ~25 copies of it to make it translatable. Approximately a continuation of T4968, the message is just less bad in that case than in this one since we fake it by piecemealing an object name into the string.

I'll take your word for it, I'm sure I'm missing something. Anywho, if there is silly grunt work I can do to help, happy to.

Another strawman - could typeahead know already attached values and only show them in a disabled (already attached) state? That if, if I go to cc @epriestley here, the typeahead could prevent that action ahead of time?

We can reasonably do that to prevent mistakes (you CC someone who is already CC'd when you load the page). We can not reasonably do that to prevent race conditions (you and someone else try to CC the same person within a few seconds of one another).