Right now, we don't track deleted MBIDs, there are several reasons why it would be a good idea:

• We can use different error codes to distinguish "this existed but has been deleted" from "we don't recognise this" (probably 410 versus 404) which allows programs to show more appropriate errors (e.g. Picard could say that a release has been deleted, instead of simply saying it couldn't be loaded).

• If we do MBS-8238, we can use it to avoid ever reassigning an MBID.

• If we do MBS-709, we can use it to create an edit history link for deleted entities without having to assume that any 404 is a deleted entity.

We would be able to recover a lot of deleted MBIDs from various sources. I had looked into this when I was trying to make a mapping of row IDs to MBIDs which could be used for making MBS-709 work for older edits. We have replication packets going back to July 2010 (#40000) on the ftp server and I managed to get about 800 older ones from the Wayback Machine too. The pre-NGS data dump has all the MBIDs which existed right before the migration and apparently the artist_deletion, label_deletion and series_deletion tables never get emptied either.