The page Total Nonstop Action is in there with two different page ids, so that reflects the state of the database when the stubs were dumped.

<title>Total Nonstop Action</title>
<ns>0</ns>
<id>454401</id>

vs.

<ns>0</ns>
<id>2547790</id>
<revision>

The page Ida de Grey has the same situation.

<title>Ida de Grey</title>
<ns>0</ns>
<id>22871284</id>

vs.

<title>Ida de Grey</title>
<ns>0</ns>
<id>31345536</id>

This likely is an artifact of how MediaWiki handles certain page moves these days:

08:39, 4 February 2016‎ Oknazevad         (59,374 bytes)   (Oknazevad moved page Total Nonstop Action to Total Nonstop Action Wrestling over redirect)
08:33, 4 February 2016‎ Galatz            (59,374 bytes)  (Galatz moved page Total Nonstop Action Wrestling to Total Nonstop Action over redirect) 
08:31, 4 February 2016‎ Oknazevad         (59,352 bytes)  (Oknazevad moved page Total Nonstop Action to Total Nonstop Action Wrestling over redirect)
03:41, 4 February 2016‎ Anthony Appleyard  (59,374 bytes) (Anthony Appleyard moved page Total Nonstop Action Wrestling to Total Nonstop Action)

and

22:29, 3 February 2016‎ Chchn   (6,952 bytes)   (Chchn moved page Ida Cockayne to Ida de Grey over redirect)

I won't be able to fix this in the dumps but I can look at the move-related code and see what happens. I guess that the move consists of multiple transactions and that at some point both the old page (the redirect) and the new page have the same title. This smells to me like a bug indeed but as I don't know that code, I can't be sure.

I checked the MovePage code and it looks like there's an Atomic wrapper around everything so I'm going to pass this to ... who does MW core any more? Anyways, to "someone" to look at possible MW bugs.

There's a UNIQUE index on the page_namespace, page_title so, even considering that the dumper ran at the same time that the page was moved, I don't see how this could happen.

Does the dumper run at a lower transaction isolation level, or are there several connections when generating the list?

The stubs are generated in 27 parts, all running at once. It's possible for transactions from two separate stub runs to reflect differing data. Weeding that out would be prohibitively slow as the dumps are currently generated. I have not checked to see if these two pages with the same title were in different stub chunks or not, but I can have a look.

That seems the most likely explanation.

I see this marked as "done", but enwiki-20200401-pages-articles.xml has still this problem.

See my comment above. This is closed as declined (essentially 'wontfix") given that it's unsolvable without a consistent view of the database across the entire time that the dump runs, and that is not feasible with the current architecture.