(Sorry, typo'd my own name into another @ep....)

I believe D20336 fixes the primary practical issue here, by adding a "View All Results" button to the bottom of query panels (including query panels inside tab panels), when there are more results:

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: