Moving rows about within or between tables would be easier if each table was not a single solid block of data, but with each row separate and the central body of the table as a list of n pointers, if the table has n rows. Then, for i = 1(1)n the i-th pointer points to the i-th row. See https://en.wikipedia.org/wiki/Iliffe_vector

When undeleting a page, you may have to pick which of multiple deleted pages with the same title you want to undelete

The technical implementation of that action must not move rows between tables.

The idea of "deleting" a revision is confusing.

AntiCompositeNumber wrote ::

... Complex history merges and history splits ... using a combination of page deletion, selective restoration, and page moves. Simple histmerges can be accomplished using Special:MergeHistory, but histsplits and complex histmerges can not. ...

If "deleting" and "hiding" are amalgamated into one system, we will strongly need something to replace this difference :: when a page is moved, a non-"deleted" edit is moved and a "deleted" edit is not moved; but moving is not affected by whether or not each edit is "hidden".

Above is written:

An important difference between deleting and hiding (as defined in the message above) is that, if a page is moved, hidden edits move along with it, but deleted edits do not move along with it. This is important in history-merging and history-splitting. @Setian @Aklapper @Izno . We need to keep both facilities: deleting and hiding.

See https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard#Deleting_part_of_of_page%27s_edit_history for this idea re-surfacing. I do much history-merging in the English Wikipedia, and in the course of that I have picked up a few things.

Many of the history-merge requests that I get are not suitable for Special:MergeHistory , but are done quicker (or only) by the old method. Please keep selective undelete of edits, and please add selective delete of edits. Removing the ability to selectively delete a page's non-deleted edits and also the ability to selectively undelete a page's deleted edits, would handcuff me badly. As well as requests for clean classical history-merges, I also get requests for various sorts of tidying-up after many sorts of unwise actions by users.

See https://en.wikipedia.org/wiki/Talk:Black_sheep/Archive_1#Moves,_merges,_history for a complicated job that I had on 11 October 2007 tidying up pages about "Black Sheep".

... and "deleted revision" could refer to either a revision that's in the archive table because ...

In my experience, if I do not have selective delete of edits, I would certainly need selective undelete of edits like we have now.

If there was a "selective revision move" feature ...

I have now read https://www.mediawiki.org/wiki/Manual:RevisionDelete and https://www.mediawiki.org/wiki/Manual:Revision_table

! In T213617#4987163, @Setian wrote:
Would you actually use a "delete them and rename them at the same time" option pretty frequently? What's an example of a situation where you would do that?

In an edit history of non-deleted edits (e.g. https://en.wikipedia.org/w/index.php?title=Scuba&action=history ), the details of each edit include a small square check. That is to select edits to be hidden. But with some reprogramming it could also be used to select edits for other purposes.

More simply :: sometimes in my work, I need to delete some edits of a page's edit history. But I cannot :: I must delete all of that page's edits, then undelete some of them. That wastes internet link time and Wikipedia server time. That is why selective delete is needed.

Other notes
I have written Proposal 1 at the Community Wishlist Survey 2019, ...
One administrator on Wikipedia who frequently does history merges is Anthony Appleyard. If either proposal passes, then that user would have to start using "Special:MergeAndMove" to do history merges, and would no longer need to "revert histmerge junk" after doing so.

If I am asked to history-merge page X (source) to page Y (destination), problems that arise are:-

1. Edits made to X after the cut-and-paste event: redirects, BattyBot and other bot edits, edits by someone starting a new article on the subject X or on another subject also describable as X.
2. Edits made to Y before the cut-and-paste event, often including redirects.
3. Miscellaneous old or new pre-existing deleted edits listed at page name X or Y.

In T20493#4446127, @GeoffreyT2000 wrote:

(1) One long-term fault is that an admin can't delete some edits of a page, but he must delete all the edits and then undelete the edits that he wants to stay undeleted. That wastes his time and Wikipedia's system time. This need arises if he is history-merging X (older page) to Y (newer page), and first he must lose from the end of X any stray late edits (e.g. redirects and BattyBot edits) made after the cut-and-paste event. This process is liable to accidents if the page already has deleted edits at the start of this process.
(2) Currently, moving a page only moves the undeleted (visible) edits. It would be useful if it was also possible to move only the deleted edits, when fishing deleted edits out from under visible edits , to prevent the sort of accident described at the end of (1).