What's the use case of moving such pages in File namespace? The pages should be deleted as they should not be created in the first place [1]. And indeed your two examples above have been deleted, only the pl.wikisource one remains and you created it for the purpose of this report.

[1]. The real bug here, I think, is to disallow creating pages in the File namespace completely. Commons and Enwiki (and probably other wikis) already have policies to speedily delete such pages. It should be enforced by the software.

In T227590#6042735, @Ammarpad wrote:

What's the use case of moving such pages in File namespace? The pages should be deleted as they should not be created in the first place [1]. And indeed your two examples above have been deleted, only the pl.wikisource one remains and you created it for the purpose of this report.

[1]. The real bug here, I think, is to disallow creating pages in the File namespace completely. Commons and Enwiki (and probably other wikis) already have policies to speedily delete such pages. It should be enforced by the software.

These were rare cases, but I needed them while manipulating page history. I know two cases:

• some edits were errorneously assigned to wrong files (likely due to some bug) (description of file A was assigned to file B and description of file B was assigned to file A; and the bug was not only about wikitext, but concerned revision description, also)
• a file with deleted revisions was moved; and the revisions needed to be undeleted and merged with the file history after the move (they remained under the old filename)

In T227590#6042811, @Ankry wrote:

• some edits were errorneously assigned to wrong files (likely due to some bug)

In that case, the bug should be reported so that the root cause can be found and fixed to prevent more assignment of erroneous edit in the future. Masking the problem by manual workaround is not a good solution in my view.

• a file with deleted revisions was moved; and the revisions needed to be undeleted and merged with the file history after the move (they remained under the old filename)

That looks like a separate bug to me. When a file is moved, the software should move it with its complete revisions deleted or not deleted. No revision should left behind for human admin to manually later 1. undelete, 2. merge, and 3. re-delete again.
I cannot verify this bug myself though. If you can confirm that's the case, it should be reported as a distinct bug.

In T227590#6042974, @Ammarpad wrote:

In T227590#6042811, @Ankry wrote:

• a file with deleted revisions was moved; and the revisions needed to be undeleted and merged with the file history after the move (they remained under the old filename)

That looks like a separate bug to me. When a file is moved, the software should move it with its complete revisions deleted or not deleted. No revision should left behind for human admin to manually later 1. undelete, 2. merge, and 3. re-delete again.
I cannot verify this bug myself though. If you can confirm that's the case, it should be reported as a distinct bug.

I disagree. Moving also deleted images when undeleted ones are moved, will make current history splitting process impossible.
The process is

• delete all revisions
• restore only the revisions that should be moved under another name
• move the file/page without leaving a redirect
• restore remaining deleted revisions

In T227590#6042974, @Ammarpad wrote:

In T227590#6042811, @Ankry wrote:

• some edits were errorneously assigned to wrong files (likely due to some bug)

In that case, the bug should be reported so that the root cause can be found and fixed to prevent more assignment of erroneous edit in the future. Masking the problem by manual workaround is not a good solution in my view.

This appeared during some incident with a broken software version, never observed again.
Our volunteer time is limitted, and sometimes we have to choose whether to fix on-wiki results of bugs or report side-effect issues that are unlikely to be useful for anybody in future.

Definitely worth reporting if this happens again. But neither reporting this, nor fixing the underlying software bug will fix on-wiki results of the bug, which this task is about.

Bugs happen (even if they should not) and we need to be able to do maintenance tasks to fix the result of the bugs (not ignore them or consider them non-existent)