Let me try to say this differently:
Headers should be compatible between HTTP and mail: that is,
a single message header should have the same meaning, no
matter which protocol is being used.
Accept-Language already has a meaning in HTTP. If you want
to use it in mail, you should only use it with the same meaning.
Do not attach new meanings to the same header. If you really
need a different meaning, then use a different header name.
I disagree that the reasons for accept-charset in HTTP apply equally to
mail.
1) In mail, the lack of interactivity significantly raises the
importance of using a canonical format over the importance of having the
sender avoid the cost of converting from local form to canonical form.
2) Time has passed on since accept-charset was designed. The report of
the IAB Character Set Workshop strongly recommends transitioning to
ISO-10646 based charsets, such as UTF-8 and/or UTF-7.
I don't see what these have to do with it; you might as well just
assume you can always send UTF-8, then. Whether or not "Accept-Language"
is present in the message doesn't have much to do with it.
In fact, "Accept-Language" is a misnomer; it should probably have been
called "Prefer-Language".
If you want to have a header that means "You can reply with UTF-8",
why not make it "Mime-Version: 1.1" or something; the appearance of
accept-language is not by itself an indication of anything other than
language preference.
Larry