For text that doesn't contain many '='s, the "7" is so similar to the
"Q" encoding that it doesn't seem worth the effort to define both.
For non-MU text that *does* contain some '='s, *requiring* it to be
distorted and lengthened seems a bit unreasonable. Of course, only
pieces of text that are safe in the context of the encoded-word can be
given a label of "7", but it seems like "7" would be desirable when
"B" and "Q" are not needed.
If the only objection to "7" is that it takes some effort to define
it, I will happily write the prose! :-)
On the other hand, if someone can demonstrate that "7" would be
harmful, we should consider that. But I doubt that anybody could come
up with an argument that couldn't also be said about "Q".
An implementation of "Q" is required to scan the text that it is about
to encode, and if it contains "?=" then this must be quoted since it
is the end-of-encoded-word marker. Similarly, if the text contains
"<" and the encoded-word happens to be in a To: header, then the "<"
would have to be quoted to avoid clashes with addresses of the form
<user(_at_)foo(_dot_)com>. And so on.
When the "Q" implementation has finished scanning the text, it can
look back and say "Hmmm... there was nothing dangerous in that text,
except for a couple of '='s, so I guess it's OK to give this thing the
'7' label."
So, as you can see, from the implementation point of view, there is
nothing difficult about supporting "7" if you are considering
supporting "Q" anyway.
(Which reminds me of the reason why some of the Japanese want to
mandate "B" for iso-2022-jp: "Q" is a pain to implement. This then
brings up the question: Shall we scrap "Q"? But it's probably too
late now. (Unless there is *no* or only one "Q" implementation right
now, in which case "Q" should(?) be removed for 1342 to go to
"Draft". How many "Q" implementations are there?))
Regards,
Erik