It seems like the dependency between the page_id and the MediaInfo item id is baked in at a very deep level

For example, here's the call chain for getting the MediaInfo item with id M1234

$entityId = new MediaInfoId( 'M1234' );
$entity =  WikibaseRepo::getDefaultInstance()->getEntityLookup()->getEntity( $entityId );

calls

RevisionBasedEntityLookup::getEntity( $entityId );

calls

WikiPageEntityRevisionLookup.php::getEntityRevision( $entityId );

calls

WikiPageEntityMetaDataLookup.php::loadRevisionInformation( [ $entityId ] );

calls

MediaInfoEntityQuery.php::selectRows() to get rows from the page table, which creates a condition for the query using getConditionForEntityId() which sets 'page_id' => $entityId->getNumericId()

... or in other words, to retrieve the MediaInfo data for an item with id=M1234, it must be stored in a slot on a page with page_id=1234

Or, in other words, the id of the entity id irrelevant - what counts for retrieval is the id of the page

Unpacking this would require a lot of work, and a new way of storing relationships between entity ids and page ids (probably a new db table)

In T231646#5468101, @Cparle wrote:

It seems like the dependency between the page_id and the MediaInfo item id is baked in at a very deep level

Yup

... or in other words, to retrieve the MediaInfo data for an item with id=M1234, it must be stored in a slot on a page with page_id=1234

Yup

Or, in other words, the id of the entity id irrelevant - what counts for retrieval is the id of the page

Unpacking this would require a lot of work, and a new way of storing relationships between entity ids and page ids (probably a new db table)

Yup.
It's probably easier / better to go down the route of ensuring pageids remain the same, or perhaps allowing old revisions of an entity to actually have a different entity ID, i'm not sure if that is too evil, especially if the redirects exist for the old entity ids which they should.
"previous entity ids" could also be held within the final entity, but that has the possibility of growing without control.

... or in other words, to retrieve the MediaInfo data for an item with id=M1234, it must be stored in a slot on a page with page_id=1234

I don’t quite see the problem yet, or perhaps I’m interpreting it differently… but as far as I can tell, if you consider the entity ID to change when the page ID changes, that still works.

That'd mean we'd (potentially) have to edit the json blob for slots when a page is deleted/restored

Also - I was under the impression that Wikibase ids were considered immutable