The really big insight Linus had that Brahm apparently still doesn't want to recognize is that if that if you design what essentially a snapshotted filesystem, the merge algorithm is just a convenience. Any better merge algorithms can be added to git without touching the format. In fact any individual user can pick and choose their merge algorithm that the repository just cares about the recorded content history (which trees are parent to which trees).
I'm guessing you're referring to packed objects. If I understand them correctly they are just there for space efficiency of the filesystem that is git. They're not first order concepts on which git the DVCS builds upon, just an implementation detail.
My thinking when I posted my comment above was that any diff format used in the repository could be treated as an "internal" format, and any actual merges that you perform could use any merge strategy that they like, as long as the commit code converted it into the repository's format on the way in. Which is why I pointed out that git also uses an internal diff format. However, if your point is that hg uses an internal format which cannot store particular changes to files correctly, or requires excessive engineering, then yes, that would be a problem and I see where you are coming from. I do very much like the conceptual simplicity of git.
