Tony, I don't think I agree with your reading of the RFC.  IMO, your
inversion of test_rfc2047_without_whitespace is not correct.  '=' is not
a 'special' in RFC[2]822 terms, so the atom does not end at the apparent
end of the encoded word.  I say apparent because if I'm interpreting the
RFC correctly it isn't a valid encoded word.  I presume you are thinking
that once you've got an atom composed of several encoded words, there's
no reason not to parse them into individual words (and I'm inclined to
agree with you), but the RFC BNF doesn't support that interpretation as
far as I can see. That is, there is no indication I could find that an
atom can be composed of multiple encoded words.

The encoded word followed by a 'special' is more subtle.  In section 5,
the RFC says:

     An 'encoded-word' that appears within a 'phrase' MUST be
     separated from any adjacent 'word', 'text' or
    'special' by 'linear-white-space'.

This would apply to encoded words in names in To and From headers. But
in other places where an encoded word can appear the requirement of
white-space separation from specials is not asserted.  It's not clear
how to make this RFC compliant without implementing a full BNF parser :(

It would probably be reasonable to fix this case so that a word followed
by a special with no intervening white space was allowed.  I've attached
a test case for the 'special' example based on that idea.