Comment by jeroenhd

IMAP UIDs are guaranteed to be static and unique within a mailbox and a UIDVALIDITY. They don't just change by themselves while you're working on them because if you do you get this bridge issue. They aren't necessarily message IDs (those exist and are part of a different email standard) but clients shouldn't need them to be. If you delete a message, the ID doesn't normally change because all you do is add a flag.

Many mail clients often have a recycle bin/trash folder where "deleted" email will go. When you click delete, the application lies to you about what it's about to do and starts a move to another folder/mailbox.

This completely ignores the standard method IMAP has for deleting email. You can mark email as deleted but that email will remain stored until you call EXPUNGE (or UID EXPUNGE) on the server to empty the trash/actually delete the message. In other words, a virtual trash folder doesn't need to be stored on the server as a mailbox at all, the protocol already has a solution for this.

There are mechanisms for globally unique mail identifiers, like Message-ID, but those are part of the emails themselves and not the protocol. IMAP deals with a combined primary key of (mailbox, UID, UIDVALIDITY) and that works just fine in my opinion. If the UID ever changes, your mail client will know about this because the UIDVALIDITY changes and the cache needs to be refetched. I see my mail client as a view for the backend data, because that's how IMAP was designed.