Note that none of your examples are valid encoded words, so given that email currently does strict parsing, the fact that it is not attempting to decode those words is technically correct.  

However, I agree that it would be better for it to do a "best guess" decoding of the invalid encoded words.

It should be possible to "fix" this case by simply replacing '?==?' with '?= =?' before decoding (blanks between encoded words are ignored when decoding, per the RFC, which the author of the package producing these invalid headers probably didn't realize).

See also #1079 and #8132.

I have to think about whether or not all of these can be considered fixes (based on Postel's law) or if tolerant parsing should be considered a feature request.  I'll probably combine these into a single issue at some point.

Out of curiosity, which email program is it that is producing these invalid headers?