Can you confirm this is still present with the latest version of Nuke? If it is, I'll have a look.

I have just run into the bug, again. I can confirm it is present in MediaWiki 1.18.1.

Furthermore, I would just have to delete a large number of images, but this is impossible. Although more than the default limit of 500 images per user can be found (I used 5000 and although I did not count, the length of the created page is plausible) and are then displayed with a checkbox in front, only a subset of these can be deleted.

Please test it on any test system, for me it is sufficient to find 10 images, then only delete the first 2, and run Nuke again. The first two, deleted images are listed again, with a checkbox in front, but without an image thumb (they are, indeed, deleted). Exectuting the Nuke for the first 4 images deletes the latter two and reports that the first 2 cannot be deleted (which is correct, because they already are deleted).

I do see it with pages when testing locally.

Just noting here that I saw this too, still.

It seems the actual bug was fixed, but instead, the already deleted files are deleted again (for example https://commons.wikimedia.org/wiki/File:K%C3%B6z%C3%B6m_b%C3%B6sek_L%C3%B3dar%C3%A1zs.jpg).

I think this is ongoing in a broader sense, if I understand correctly. If you queue pages for deletion, then immediately try to run Nuke again, it will list the pages that are queued but not yet deleted, which is confusing. I'm not sure what the best solution is, though.

We could hide pages that are queued from being surfaced, but that requires some log of which pages are queued (does this exist already anywhere?). And then what happens if the queued page is not deleted for some reason - presumably we'd need to make it available for deletion again after it's no longer in the queue. Perhaps T376377 can solve the UX issue and this wouldn't be such a problem.