Benefits:
1. You can check in your code so you don’t lose your changes!
2. You are isolated from changes other people make to the code
3. Your code can be approved/verified before it effects the main branch.

Downsides:
1. Merging can be a pain in the ass…but i can’t imagine its harder than 2 people working on the esame file in the same branch

Unfortunately, I do have to deal with clients that forces the split between Inbox/Sent and also with no threading (mostly web based mail clients at this point). Up to recently, Squirrelmail wouldn’t allow you to store you outgoing mail in your Inbox. They fixed it in the latest version.

Thanks for the pointer to mutt and labeling. Looks like I’ll be going back to mutt for awhile

One problem would be that the tag wouldn’t work across email client unless there was a unified way for email client to read the tags, say x-tag or x-label.

In fact, mutt has basic support for an X-Label header since 1.4: labels can be displayed, and they can be used in patterns for searching mails or filtering folder views. And there are half a dozen hacks that retrofit adding/editing labels around.

Of course, this mean that the email itself would have to be modified by the client, although some clients already do this.

Clients using the Unix mbox format already have to do so – they use the Status/X-Status headers to track whether a mail has been read, is old, has been replied to, and/or has been flagged. (Other mailbox formats each have their own ways of storing this information outside the message.)

It’s not at all inconceivable for mail clients to reinvent the GMail labeling feature in an application-independent way. X-Label is relatively widely recognised anyway, it appears.

IMAP also defines extensive facilities for arbitrary message flags. Application support is lacking in that area though. (Honestly, the IMAP implementations in most mail clients are pretty damn awful.)