The reason for this is happening is the following code in MediaInfoHandler.php

public function getTitleForId( EntityId $id ) {
		return Title::newFromID( $id->getNumericId() );
	}

... so if you pass it M1234 you'll get the page with page_id 1234, regardless of what page this MediaInfo item is in a slot in

And that's why you get the editconflict, because the baserevid is a revision of the page that contains the slot, but the numeric part of the M-id points either to a non-existent page with no revision, or to a different page that doesn't have a revision that matches baserevid

As an example, the page https://commons.wikimedia.org/wiki/File:John_Carmack_-_The_Dawn_of_Mobile_VR_-_Game_Developer_Conference_2015.jpg contains the MediaInfo item

{
	"type": "mediainfo",
	"id": "M78910210",
	"labels": [],
	"descriptions": [],
	"statements": {
		"P180": [{
			"mainsnak": {
				"snaktype": "value",
				"property": "P180",
				"hash": "ce0cdc5a9dd96dd5deee2c39bbb73cd054c59cc1",
				"datavalue": {
					"value": {
						"entity-type": "item",
						"numeric-id": 92605,
						"id": "Q92605"
					},
					"type": "wikibase-entityid"
				}
			},
			"type": "statement",
			"id": "M43674259$9e3ad3bc-4aae-53a9-b26f-28e8cc2187d6",
			"rank": "normal"
		}]
	}
}

The id of the File page is 78910210, the id of the original page the statement was entered on is 43674259. The wbsetclaim code takes the GUID of the claim, gets page 43674259 and then tries to match it again revision id 347013814 (the latest revision of the page), fails and throw an exception

And if you don't send baserevid, the wbsetclaim code takes the GUID of the claim, again gets page 43674259 and sets the claim on that page which is https://commons.wikimedia.org/wiki/File:John_Carmack_-_The_Dawn_of_Mobile_VR_-_Game_Developer_Conference_2015_-_cropped.jpg instead

We had some discussions within the Wikidata team today and came to the conclusion that something like https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/+/573315 is probably the best thing.
This needs to be done on:

• undelete (for when page_id might change, or for the case of page history merges?)
• undo & restore (for the case history has been merged and someone desires to restore a previous media info revision that still has the old media info id in there)

We said that:

• Magically rewriting the content of the old revisions (with the wrong ids) either in storage or during presentation would probably be bad, evil and missleading.
• Ideally viewing history would just correctly render the old revisions etc.

We discussed the idea of removing the entity id from the json and also from the start of statement guids when stored and instead only showing these in the presentation layer.
This would probably be more work and risk than it is worth and after lots of discussion came to the conclusion that the extra revision and hook stuff would be better.

I would hard veto rewriting old revisions. That should never be done, unless we run a maintenance script to fix some bug and we announce it widely, and provide time for any downstream users (including dumps!) that rely on old revisions being unchanged, to update their data or scripts.

Creating a new revision with new slot record with the new page id seems right to me, at least in the short-to-midterm. I am very interested in how old revisions with the old page id get connected up to the new revision and page id, however.