Therefore, make a page move or (equivalently) page rename feature. For bonus points, leave a PageRedirect at the old location of the content, or (better) add a PageAlias to the content.
Don't allow moving pages on top of another page - require deletion first (or treat such moves as implicit deletions).
But, if you don't care about VersionHistory then it's easier just to create a new page, copying the content across, and remove it from the old page.
Implemented in MediaWiki - MetaWikiPedia:MediaWiki_User's_Guide:_Renaming_(moving)_pages
Often we use PageDeletion to rename a page. We use the DeletedPage keyword tag to do this. Why not a MovedTo? that acts similarly and avoids making hapless editors waste their time (and possibly blow the SurgeProtector) renaming all the BackLinks by hand?
This would be very simple.
MovedTo?: to be a RenamedPage
I renamed the page title because it was shorter.
The script would treat the MovedTo? tag as a combined PageRedirect and DeletedPage. When the page was finally scavenged after DelayAction, it would go back through all the BackLinks and replace the LinkPattern with the text that follows the colon. The (first) LinkPattern would be the targeted page. Note that VersionHistory would not have to be moved if the site used KeptPages, but it could be moved by a sufficiently plucky script for a site with FullHistory.
This might fail for complex WikiGrammar? acrobatics. Thus, the script should publish its changes to RecentChanges/DigestedChanges so that PeerReviewers can do the much easier task of verifying the automatic changes rather than manually having to do the changes over and over again. Of course, they may be too lazy to do this, but it's a trade off against people renaming pages when necessary vs. having a few bent sentences that red pen obsessed readers later on might fix.