Notices

Yup...

v=HTML2

The theory of relative paths.

That is not a problem of the MHT format. It's a problem with IE, if IE is used to create the files. I don't use IE, and I doubt there are many users who do, who are keen to do offline captures. IE users are, IMO, too simple to be handling web page captures for archival and offline reading.. those users are happy if they can print something.

MHT is the most widely accepted format for offline pages. I wouldn't object to MAFF if there was better support for it. Last time I checked, the firefox MAFF plugin went obsolete, and only worked with FF version 1.0.

Well, it may be a problem with IE but its also a part of the standard:

http://en.wikipedia.org/wiki/MHTML
http://tools.ietf.org/html/rfc2557

After examining the contents of an MHT file, I can see that these absolute paths are actually the original URLs on the WAN (not an absolute local path, which is what you might think considering MS is struggling with this).

This is why you can open an MHT file, and all the links actually work seamlessly if you're online -- precisely how you would expect a good implementation of an offline page to work. I've worked with other offline web archive formats that broke the option to click on unsaved links - perhaps due to lack of absolute URIs.

There's no reason why having absolute URIs in a file should complicate the support. The fact that MS can't handle it is a statement of MS, not the standard. The standard has ensured that well designed implementations can easily browse online from an offline file, and rightly so. I wouldn't have it differently.

Moreover, the standard actually allows for relative URIs (page 9 of RFC 2557), so that captured objects can have a relative reference. This makes it possible for the offline objects to be loaded, while the links deeper than the offline page goes can be used to retrieve online content.