I'm glad the comments there brought up content negotiation, where I see more underused potential as new features and plugins are developed. It also seems odd for a browser to give up control over which order resources are loaded in, in the name of performance. Haven't browser authors done a lot of work to first fetch resources they consider critical, make a usable partial rendering, and then fetch the rest?
Before people use this, I would hope they write some code to make their servers package the live resources on the fly. If an author has to do the packaging without a build toolchain (most people don't even use RPMs to get content onto production servers), they are likely to include resources some browsers wouldn't have fetched (or that many pages don't reference at all) and let it get out of date.
Since HTML5 introduce WebSocket, why don't we provide a plugin mechanism in browsers that allows downloadable site defined Internet protocols? In fact non-HTTP protocols been around in browsers since stone age, IE, Netscape and Firefox support Gopher in some degree. Chrome silently added libjingle for Bookmark Sync, it's even yields "P2P error" when something goes wrong. Opera has a BitTorrent built in.
Browser is container + Internet IO, period.
This idea should start within hacker & developer community first. I hope browsers could innovate as prosper as WinAmp developer ecosphere used to be. Not just a crappy HTTP requester+fancy HTML renderer with round corners, ogg-only audio, shinny canvas and 3D shit.
Before people use this, I would hope they write some code to make their servers package the live resources on the fly. If an author has to do the packaging without a build toolchain (most people don't even use RPMs to get content onto production servers), they are likely to include resources some browsers wouldn't have fetched (or that many pages don't reference at all) and let it get out of date.