Simply adding two position rows on the same board doesn't reproduce the exact same error, we get this instead: [Unable to find...]

Make drops when a column position already exists go through.

See PHI119. This may describe a race fixed by chaos reduction in T13054. PHI1128 is probably another copy of this, which suggests it's still a real bug.
See PHI208. This describes a performance issue on workboards with very large numbers of tasks.

After D20305, this can be "fixed" with this change:

We may still pursue this, especially after T4900, but a lot of the use cases / needs are mostly theoretical and it's not clear they're actually necessary. Some of the actual solutions (like T10335) may largely provide enough clarity about these cases on their own. I'm currently planning to wait for feedback about recent and near-future changes (including triggers) and then fix whatever issues arise surgically -- possibly through animation, but possibly through other UI/UX remedies.

Those changes haven't landed yet but I'm just going to tidy this up a little early, see T13074 for followups.

This seems to have quieted down, now.

Probably a bad idea but maybe I'll revisit this at some point.

I believe this is now resolved. See D20291 for technical details on the main issue and T13266 for a followup.

Also, what is "By Relevance" ?

I also checked for more leftovers in instances/, but it looks like we don't have any non-default paging there.

I've poked around a fair bit locally, although I'm not totally confident I got every combination of paging columns and queries. I think anything that was missed is very likely to produce an explicit error rather than mysterious behavior, so I'm not too worried about it. Stuff to keep an eye on:

I also vaguely think some mailer API historically rejected mail with a "Message-ID" header with an actual error ("You can't set this header, we're going to set it for you.") rather than just ignoring/replacing it (maybe SendGrid?), but I might be misremembering or that behavior may have changed. We could still always set the header and drop it in the Adapter nowadays, this whole thing is just a nest of hornets and kicking it has pretty limited upside.

I can imagine that cases like this may exist:

There's probably some argument here for removing this behavior and assuming we can never generate a "Message-ID", but I'm hesitant to make changes like that since client threading is largely unknowable black magic which we can not test, and the current approach seems to generally produce acceptable results without an overwhelming amount of collateral complexity.

This is an unconstructive mess that I don't specifically plan to act on. T13069 and other work may eventually resolve this case indirectly.

report back on whether it mitigates

This previous behavior violated standards — the In-Reply-To identifier is supposed to be the Message-ID of a previously delivered email — but at least it wove a consistent fiction for mail clients.

Have you possibly changed mailers from "SES" to "SES via SMTP" or something like that? The logic here is basically:

See also https://phabricator.wikimedia.org/T113556 downstream.

See PHI1125. Recent versions of JIRA (JIRA 8?) still work with approximately the same instructions, but you have to fill out a modal dialog with about 7 required fields first, and none of the fields have real values. That is, the configuration instructions for recent JIRA are:

I'm going to consider this resolved at this point. The one thing I haven't built is the "task/point count" from the mocks (on the right-hand side of the header, counting points in each group), but I think this is probably only of much use under "Group by Owner", and maybe not even then. I'm open to building this in a future iteration and it's not likely to be very much work, I'd just like to see feedback that we're generally headed in the right direction first and that the element would have real-world use cases.

Currently, you can put a task in a column in these ways:

Currently, expected behavior.

More or less resolved previously in D14918.

D19549 added Spaces support to projects.

Mooted by D20263, which removes the rarely-used drag functionality from global lists.