Conversation threading is distinct from conversation grouping, which is currently implemented. The way I understand it, conversation grouping groups messages together based on the sender and subject line. This means that emails with the same subject line that are a month apart (like bill notifications) get grouped together. This is not at all what I want.

Conversation threading, however, threads together messages based on the "In-Reply-To" header lines so it only groups messages that belong to the same thread. In this way, bill notification messages do not get "grouped" together, because each notification email belongs to a different "thread". Message conversations that utilize "reply" and "forward" are grouped together in the same thread, which is the behavior that I want.

In my opinion, "Conversation Grouping" tries to be smart and does unexpected things, whereas "Conversation Threading" is a dumb algorithm but does exactly what I would expect.

I see "Conversation Grouping" and "Conversation Threading" as mutually exclusive options, as the way messages are displayed would be the same* for both options, but the algorithm for determining which messages get grouped together is different.

*Actually, "Conversation Threading" can even be displayed better than "Conversation Grouping" as you should be able to tell which message was replied to for each message if the UI presents the connectivity of messages rather than just being flat (see Thunderbird for example).