homepage

The problem comes from thinking you can parse an arbitrary email message if it is in unicode form. *YOU CANNOT DO THAT* in the general case (ie: non-ascii attachments).
That said, the new email package API is designed to facilitate "off label" uses. I would have no problem with the definition of a policy object[*] that was basically "use this to parse messages in unicode form as long as they don't use MIME". As soon as you start parsing MIME headers, the input had better be binary or pure ascii, or the headers *won't make sense*. You break the MIME API contract if you use MIME with a non-ascii unicode string.
[*] that policy might be a clone of one of the existing policies and not actually do anything to prevent the input having mime headers...ideally it would, but I just don't want to say it is OK to use the standard email policies to do this and expect it to continue to work in the future. It probably will, but we should not document it that way! :)