* RFC 2047 is a pain in the butt
* Handling attachments can be difficult (particularly the inability to safely add binary data)
* The display name/address is both painful in terms of syntax.
* CFWS in general (you can tell who's written an email client by their reaction to the letters CFWS)
* Header fields in general have way too lenient handling, so there's no way to, e.g., guarantee non-ASCII handling (RFC 2047 needs to be handled differently in the Subject: header than from the From: header, and the Content-Type: header does something else entirely).
* Mandatory line-length limits, which means you need to be able to insert line breaks in however you encode custom header values
* No way to get attachments without the body or vice versa
* All metadata needs to be shoved into a header (see above about i18n, line length, and CFWS)
What would you add? Remove?
Why?
For myself: the basic RF282 concept of sender, subject, recipient (or newsgroup), date, and references, plus body, seem reasonable.
How best to take these to present capabilities (and needs) is another question.
Well, except for the mess that is RFC 822. At least NNTP decided to go 8-bit safe eons ago, so you just have to shove everything in UTF-8 and you can screw RFC 2047 in the face.