Comment 3 for bug 365270

yes - Sebastian - it is consistent.
You can make another folder than Inbox, "touch" and email and try to drop it into the new folder.
What happens is that the email ends up in the new folder - but a copy of it is in the "Deleted Items" /"Trash" folder.
This means that a duplicate has been created.

Then make a Message rule that moves messages from e.g. a named sender to the new folder - and the result will be the same on receipt: one copy in the new folder and a duplicate in Trash.

Related to priority - i have a long experience in database development - and can tell you that the bug is fundamental, and is consequential to a number of other bugs reported.
It renders all "Message rules" useless - because it results in messages being deleted.
It is critical, because nobody can use an email client that causes messages to be lost.

Make a version that processes one email account at a time - avoiding multiple streams allocate new message indexes. Then when you have verified that the message has been moved properly, delete the content by releasing the message index of the original. If the two does not compare after "move" - then delete the new index (best also notify that the move failed for some reason) and release the message index to the new - and hold on to the old index.

What happens now is that the message index of some other stream uses the same message index, causing the emails to get lost - or "deleted".

It is not a desktop bug - it is a bug in the core system.

You have to consider concurrency and you cannot make duplicates to delete them later.