Note that In-Reply-To can also contain multiple message ids: <https://tools.ietf.org/html/rfc5322#section-3.6.4>.
It should be treated the same as References.

When you say that a message_id parser exists, then that means it is not applied to the Message-Id header by default yet, because my example shows that the Message-Id header gets mangled.

Applying encoded-word encoding to (unknown) unstructured fields may break workflows. These are often X-… headers and one cannot assume that the application generating and consuming them apply decoding. (Just as with message ids.) The most reliable approach would be to not encode them, but apply white-space folding and then leave them to go beyond the limit set (78 characters, typically). As headers, the increased line length is not that big of a problem. (The 78 limit is for visual reasons.) In case the lines still go beyond 998 characters, an error should be raised, as that is an RFC violation. Tools generating such headers are severely broken and should not get a free pass. Users could get the option to allow such lines and take their chances when the message is submitted and transported.