immutable commit messages, why?

[Stuart McGraw]

The "obliterate functionality" thread prompts me to post a somewhat related question I have wanted to ask for a while...

Why are commit messages immutable?  They are (in theory) not really part of the state of a set of files but rather meta-information about that state, yes?  

This issue is preventing my adoption of a DVCS.  I have a CVS repository in which a number of commit message are wrong, misleading, vague, or otherwise sub-par.  I not infrequently need to find previous work based on these messages.  As I find problems or have time, I fix bad commit messages by editing the CVS repo files in-place.  But once I import this repo into Mercurial (or any other free DVCS AFAIK [1]) the commit messages will be set in stone for all eternity, so I have put off making the jump.

I suspect the real reason commit messages are revision controlled is that DVCS' have a hammer for managing immutable revisions and it was more expedient (and seemed cool) to shape commit messages into the form of a revision nail, than to invent a whole separate mechanism for managing them.  And that poor commit messages aren't a show-stopper problem for most users so they are simply lived with.

I can imagine a DVCS where the commit message do not participate in the revision hashes and have a timestamp or independent hash.  When a merge having changesets with differing commit messages is done, the merger would be asked (or a configured policy consulted) to determine which to accept.

While it would involve some significant reengineering of Mercurial to do something like this, are there any reasons doing so would be a bad idea?
----
[1] T believe the commercial product AccuRev has non-immutable commit messages and considers it a feature.