We have noticed in our organization that it does not always work like 
this. Our users complained that the the notification was mostly 
useless, irritating and distracting.

Thanks for the hints on how to remove that notification.

1. User installs Windows.
2. User selects the language for the OS.  I'm going to go ahead and 
make the assumption that this is a language that the user understands.
3. This language is indicated

The Accept-Language header has *nothing* to do with the language of 
the current message.  It is simply an indication of languages that the 
user has explicitly indicated (by some means) that they understand.   
It is not meant to be an exhaustive/exclusive list.

Here is the usual situation:
1. Friend uses Exchange system with Outlook.
2. Outlook attach Accept-Language header based not on the actual 
language of the message but based on system locale or installed 
language pack
2. Accept-Header in this case is false, but he has no way of changing 
the value
3. When message is replied in Horde system it tries to parse 
Accept-Language header, which obviously contain false information. 
Accept-Language is not in this case the language that the message is 
written in, what sender system accepts or what sender prefers.
4. Horde show this Accept-Language information.

Is it problem in Outlook or Exchange? Possibly.
Is it a problem in Horde? Possibly. Because in this case it works 
differently from other mail clients that happily discard 
Accept-Language value or at least do not show it to user. User is not 
expecting to see that notification.

I've now locally removed that message from the compose templates.

Are you both talking about the same thing here? As far I know, the 
Accept-Language header is set through a (Horde) user preference and 
has nothing to do with the language setting of the browser. So 
regardless of the number of locales and language packs, it would still 
only show the languages the user has configured.

Example: I use Finnish as a language to write messages, but I use 
en_us locale or language pack. The Accept-Language is then only shown 
as "en". This does not mean that I wish everyone would reply my 
Finnish messages in English or I can only receive messages in English.

What happens when someone uses multiple locales and language packs. 
When does the language list become too long.
A setting would be preferable.

No, we *are* using it correctly.  In the scope of e-mail, 
Accept-Language is used to indicate which languages a user can read 
mail in.  We show this information to the composing user, so that they 
can adjust their composition accordingly. Most important, we do *NOT* 
do any sort of automatic action based on this header.

If you don't want to show this information locally, you can alter the 
templates/CSS to hide the data.

Problem: Imp actually tries to use Accept-Language and shows the value 
to users. Accept-Language does not really show what language the 
message is, but what language pack or locale sender uses.

Proposed solution: Ignore Accept-Language header and value it might 
have. Other mail clients do this already.

This bug is also present in development versions.

These mail clients just ignore the value in this header: Thunderbird, 
Outlook, Apple Mail App, Windows Phone 7 client, Symbian Mail Client.

Note that RFC 4021 recommends that Accept-Language might be useful in 
generating automatic replies:
Indicates a language that the message sender requests to be used for 
responses.  Accept-language was not designed for email but has been 
considered useful as input to the generation of automatic replies.

W3.org documentation does not recommend using Accept-Language alone to 
determine language:
http://www.w3.org/International/questions/qa-accept-lang-locales