Wouldn't it be better to at least make that convenient rather than copy-paste from the screen?

I would just like to stress the semantic difference (as well as HTTP and filesystem differences) between downloading a data file (a 'download button'), and viewing the raw data. The latter would provide convenience for either direct access from a script with suitable credentials, or manual handling without the extra auth code. I believe you're less likely to end up with stray data using this 'inline' method.

One of the first things my script says it to securely handle and promptly delete any data. I'm pretty sure many checkusers handle local text files on a temporary basis - not for record keeping but to juggle the amount of data we sometimes have to look at. It's not something I particularly recommend though, especially if you're not disciplined in dealing with secure data. I'm not really a fan of just having a download-file button for several reasons.

An option to display 5,000 records per page would also get around the immediate issue. It doesn't need to be 5,000 (enwiki admin elections number around 600-ish), but that seems to be the norm.

The script is on cuwiki, but I don't think that's important. It reads the data as you would see it on the 'vote list' page, from a local text file, in tab-delimited (TSV) format. Fields include timestamp, name, duplicate, IP, and the rest, as it's displayed in the list table. It reads from a text file because it's too much coding-faff to log in and read directly from the site. The script is not public.

I seem to get this consistently using the dropdown at the bottom of the list. It just refreshes the list (and limit) being currently displayed.
The top dropdown seems to work fine.

I'm experiencing this same issue at File:Donald Trump mug shot.jpg on enwiki (also see its talk page). The file still has all the description pages.

I've come across this 4 or 5 times in the past day (I'm a checkuser so I do a lot of this stuff). Anyway, the second problem, with autoblocked globally locked and hidden accounts, may be related to a global IP block which is now in place. I have limited opportunities to test this.

My only concern would be ranges which don't adhere to the /64 rule. A notable example is AT&T, for example 2600:387::/32, where users generally hop around within a /48 or larger, and a limited number of /64s are shared. If a filter is being pestered by such an IP hopper, this is going to rapidly propagate throughout the entire usable customer range, causing certain collateral. I've seen other ranges like this, but admittedly there's not many. If this was on enwiki, where we don't currently have any filter blocking enabled, we'd probably sometimes want to exclude these ranges from any blocking filter Saying that, I don't see a checkbox as a particularly useful way of achieving this.

I haven't seen this error in the last couple of days.
I suggest whatever was affecting checkuser has probably been resolved.

I've been getting this intermittently through checkuser since around Thursday afternoon (UTC).