The work I've been doing on email6 has reached a stage where I'm confident about the overall plan of the new code, and am ready for people to review it and make suggestions.  The patch represents a working state of the code, but with several omissions that I will continue to work on while the rest of the code is reviewed.  The major omissions are that address headers don't yet handle encoded words in their 'value' and related attributes, and that structured headers do not properly support unicode characters when the message is flattened.  (The traditional email5 methods for handling unicode in structured headers still work fine, though).  There are also edge-cases where the address parser does not do as well as email.utils.parseaddr (and other cases where it does better).

A goal of email6 is to be 100% backward compatible with the existing email5.1 API.  If you find any deviations please let me know.

A new policy, email6_defaults, allows you to run the code with what are intended to be the defaults in Python 3.4.  (Not specifying either email6_defaults or email5_defaults when creating a message will result in warning messages in cases where it would make a difference which policy was in force).  The only difference between the two right now is that email6_defaults sets 'use_decoded' true, which means that the string value of header objects is the fully unicode version, not the ASCII-only version that comes from the source as is true with email5_defaults.

I've also released this version of the code as email-6.0.0a1 on pypi, so that it can be tested using 3.2 (you import it as 'email6').

I will separately attach here the README from the pypi package, which details the header features that are finished and the ones that still need work.

After review, I'd like to go ahead and check this in to default and continue the work from there.  From this point until I start work on the message_factory all changes will be incremental.  When we originally planned out email6 we thought we'd be making a "compatibility break" with backward compatibility shims.  As things have turned out the work is more a matter of incremental improvement of the API while maintaining the old API, and thus it seems reasonable to me to work on it directly in default rather than continue to work on it in a separate feature branch.

If, that is, the approach here is accepted :)  The email-sig seems to like it.

Oh, yeah, and there's room for plenty of bike-shedding about certain attribute names &c.