After tracing the code further I now understand what the original patch is doing, and yes the spelling correction is the correct fix.  (The issue is that there are two different encodings involved: the input encoding in which the body is encoded when encode_7or8 bit is called, and the 'output' encoding that will be used to render the message when it is serialized to bytes.  In the case of iso-2022, it is used as the output encoding for at least one input encoding that is an eight bit encoding.  iso-2022 is pretty much the *only* encoding that appears as an output encoding different from the input encoding.)

Applying the patch will have to wait until the branch unfreezes.  I also think that I will not apply it to 2.6, since it is not fixing a bug that anyone has reported as breaking their code, but does represent a behavior change.

Since we have proven in the course of analyzing this that the code is untested, perhaps someone would like to write some unit tests for it?