I have no clue to your background - not have you any clue to mine.
I have led Unix ports for a computer company and been deputy director of
R&D in the same. I have lead knowsoft systems such as Oracle ond also
contributed to Sybase. I have managed huge projects, most software.

The bug is obcious for all variants of "Move Object" - C- library: 
Move(a,d,l) { char *a,*d;int l;
            memcpy(a,d,l);
            if (memcmp(a,d,l)==0) {
                    memset (a,sizeof(a),0); return OK;
            } else {
                    memset(d,sizeof(d),0);; return ERROR;
            }
}

The context is more complex, since you have to make room for
objects/emails as this goes on.You have to allocate slots first for the
incoming mail - and map this to the "Inbox". Then say a rule says that
the message is to be placed in another folder F. So the email client
will alocate a new memory slot in Inbox for the email. I would keep this
as an array of pointers to objects - and have the same array of pointers
for every "mailbox".

First the Move from Inbox to F is a copy operation - holding on to the
index in Inbox. But if a new message comes in from another stream, the
code has to decide if the slot "i" in Inbox can be used - or if this is
the "next" email - "i+1". Say that it allocates the next slot to
position i+1, and the order of things is maintained as a separate list.
Should the code re-use "i" - the "move" has to be successful or the
email is lost. 

Regardless - no "Move" is performed - just copy, but where the
successful "copy" ends the completed object in Trash. Then what is te
first "Free" index in Inbox? If the "Copy" is ongoing - what is the
"Next" free slot in the Inbox?

When you make a rule e.g. "where Sender with this email address, the
email should be moved to Folder" . there is not "Delete" in the
semantics - the code may skip storage in "Inbox" - and store directly in
"Folder".

When you touch a file, press shift and drags it to another directory,
there is no file placed in a Trash directory. Similar, when a rule exist
that says that an email is to be delivered in another folder, the
"Inbox" may be replaced with another destination for first storage.

If you make a duplicate by "Copy" - you have one slot too much, and I
consider it likely that the wrong copy is deleted.When I then find error
reports of lost messages, I considered this as the most likely
inconsistency - where the wrong copy is deleted. The other error is that
the code allow multiple streams - and thus that another email can ask
for a new slot in the "Inbox" while this creation of duplicates is done
- then which copy is the correct. If you want to compare to make certain
that the "copy" was successful is impossible to conduct, since another
thread may already be using the source memory slots.

The code is usually very simple, and a simple directive as "Move" -
should be very simple and verified over and over again.It is a core
functionality, it is consistent in use and can be reproduced every time
you try to "move" anything.

It is critical, since the error causes mail to be lost.

I cannot waste time on software like this and consider replacing
"Evolution".

Kind regards
Knut H. Flottorp
On Sat, 2009-04-25 at 17:25 +0000, Sebastien Bacher wrote:

> the description is confusing, that way to move is a standard imap one
> and if you disagree you should open a bug on bugzilla.gnome.org to
> discuss it with the people writting the software


CONFIDENTIALITY AND DISCLAIMER NOTICE This E- mail message (including
any and all attachments) is covered by the Electronic Communications
Privacy Act 18 U.S.C. 2510-2521, is confidential and legally privileged.
In addition, the information contained in this E-mail message is
personal and confidential and is intended for a specific individual (s)
and purpose and therefore is protected from disclosure under the
Framm-Leach-Bliley Act. The sender is not a licensed securities
broker-dealer. This E-mail message is neither a solicitation of
investment nor and offer to sell and/or buy securities. If your are not
the intended recipient, you should delete this message immediately
and/or any of its attachments and are hereby notified that any
disclosure, copying, or distribution of this message and/or its
attachments, or the taking of any action based on it, is STRICTLY
PROHIBITED as noted above. If you have received this communication in
error, please notify the sender (return the email as an attachment) and
erase this e-mail message immediately. Any views or opinions presented
are solely those of the sender and do not necessarily represent the
Group or its companies unless otherwise specifically stated. As Internet
communications are not secure, we do not accept legal responsibility for
the contents of this message nor responsibility for any change made to
this message after the original sender sent it. We advise you to carry
out your own virus check before opening any attachment, as we cannot
accept liability for any damage sustained as a result of any software
viruses.

________________________________________________________________________