Presumably obsolete since this hasn't cropped up again.

After a few followup fixes, this now appears to be working. Remaining stuff I'd like to do:

Optimistically assuming we got most of these, since the ones we missed were weird and obvious and nothing new has turned up for a bit.

This more or less exists, now. See T13269 for followups and T13074 for additional context.

See PHI119. PHI1128 is probably another copy of this, which suggests it's still a real bug.

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.

Just ran into this issue on a freshly installed Ubuntu 16.04 docker container.
Actually it's just the package phpX.Y-xml what is missing.
In my case it was php7.2 so all I needed to do was:

sudo apt install php7.2-xml

(No extra repositories needed...)

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.

We should log all the paths used to get to each page, and then show all of them in a big combo box, and when you select one, update your browser's history to match that path!

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 was imagining keeping the Message-ID, while having the first email also include the same value for In-Reply-To — I completely agree that removing the Message-ID would not work out. If the first email always included both fields, thus referencing itself as a reply to itself, I suppose there could be MUAs that would go into infinite loops. So, maybe too risky.

I can imagine that cases like this may exist:

The only effect I can imagine of always setting the In-Reply-To would be to encourage threading where it's not currently happening, so removing the behavior and deleting all these little methods would be very attractive to me if it were my project. :)

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.