No it won't. It is still easy to make collisions with a known prefix or suffix. You would have to include a random component.
Even if that was a feasible workaround, it's hardly a common best practice, nor should it be.

He discovered this vulnerability himself, and wrote the attack code; he is by definition not a script kiddie. Never mind that he's a professor and published cryptographer.

This has nothing to do with being experimental software. This is not a bug, it is a weakness in the design. Furthermore, the bad behaviour will not manifest by accident - you have to deliberately provoke it.
This is the type of problem that isn't fixed before someone finds and reports it -- like Junod did.

Please cease your inane babbling.

Also be sure to check out the brilliant paper recently published by Hakin9 in their issue on Nmap.

The authors detail the working of their DARPA Inference Cheking Kludge Scanner (DICKS), and cite such prominent references as
Z. Sun, "Towards the synthesis of vacuum tubes," Journal of Concurrent, Extensible Technology, vol. 84, pp. 1-19, Feb. 2005.
C. Hoare, J. Wilkinson, and D. Ritchie, "Contrasting Scheme and Internet QoS using SluicyMash," Journal of Flexible, Omniscient Epistemologies, vol. 20, pp. 154-194, Feb. 2000

Some excerpts:

"Obviously, event-driven modalities and web browsers are based entirely on the assumption that extreme programming and digital-to-analog converters are not in conflict with the deployment of massive multiplayer online role-playing games."

"We show our method's real-time evaluation in Figure 1. We consider a framework consisting of n flip-flop gates. Such a claim might seem counter intuitive but is derived from known results. Next, NMAP does not require such a theoretical emulation to run correctly, but it doesn't hurt. This seems to hold in most cases. We use our previously enabled results as a basis for all of these assumptions. This seems to hold in most cases."

"Figure 1.3: The 10th-percentile latency of NMAP, as a function of popularity of IPv7"

Er, or even <script src="foo" iamnotadocumentwriteusingidiot="1">

Some web browsers just render the page assuming that included scripts won't call document.write(), and then render the page again when the scripts have loaded, in case they do.
I think Chrome does this, and Opera has it as an experimental option in opera:config ("Delayed script execution").
It speeds up things a lot, especially if you aren't blocking ads. Many sites spend most of their loading time just waiting for ad servers.

There ought to be an attribute or something that webmasters could use to explicitly request XHTML semantics... Something like

Tying NaCl to a specific architecture was a very bad move in the first place, and PNaCl doesn't help a lot.
LLVM bitcode isn't intended to be a platform-independent transport of code - it isn't frozen, so you'll have to tie yourself to a specific LLVM version, while LLVM is still improving a lot with each release.
Neither is it very portable - it isn't endian independent, and it reflects details of the ABI, which means you can't even portably call C functions. It's really just a compiler IR.

See also e.g. this post.

I can certainly see reasons that you'd want to tie a VM to the browser instead of being stuck with ECMAScript for every situation, but you need to bring a real, portable VM to the table. LLVM isn't it, and the idea of putting architecture dependent binaries on the web is patently ridiculous, as should be obvious just from the time NaCl spent as x86 only. Imagine if web site owners had to recompile their site for every new architecture that became supported. "This site is best viewed on a x86"

A CA could be one such authentication step. Consider a network of independent notaries to which the CAs could securely push public certificates and tie them to a domain name.
Now you have to compromise the CA (or a sufficient number of the notaries, some perhaps run by the CAs themselves), and you have to perform the MITM upstream, not downstream, so the perspectives-like notaries will still see a consistent view.

What does this gain you over storing the cert signature itself in DNSSEC?

Nothing prevents a notary from taking extra steps to verify the authenticity of a certificate. That is one of the advantages of the concept: other methods of authentication can be added in a modular way.
In some ways the notary system gives you the security of the strongest of the notaries you trust, and the CA system gives you the security of the weakest of the CAs you trust.

The communication with the notaries is in all likelihood encrypted and signed with predistributed keys, similar to CA certificates today. That's not a large problem, because ultimately you have to trust the software you are running anyway.
That still retains all the benefits over the CA system that you mention; you get multiple points of trust that all have to be compromised, and if one is compromised you can distrust it with minimal consequences.

We do have some idea.

We know that Microsoft is approaching this in pretty much the most scummy and mafia-like way possible, using strong-arm tactics to make companies sign NDA agreements to prevent information leaking out that would allow other companies to protect themselves ahead of time.

We know that the patents that we have seen, mostly thanks to B&N having some balls and not falling for the MS's cheap tricks, are dubious and certainly not worth what Microsoft is demanding, given that you can licence Windows 7 for about the same price.

I personally know that I'll do my best to not give MS a dime of my money, though they sure know to take their rent from PC and phone manufacturers, and in fact I'm glad this story came up, because I was about to inadvertently buy some of their hardware, but come to think of it I won't, because who wants to subsidize shit like this?

To be honest, while id Tech 5 with its heavy focus on textures is an interesting experiment, I'm looking a lot more forward to id Tech 6. It looks like it will use raycasting on sparse voxel octrees, same as the Unlimited Detail guys. That will by all accounts amount to a generational leap in graphics, doing for geometry pretty much what MegaTexturing does for textures.

John Carmack has been talking about voxels since 2008, but the hardware weren't up to it back then. Apparently they're doing research on id Tech 6 now.

While the Unlimited Detail guys have made some promising demos using static geometry with static lightning, I believe rendering a more dynamic game world with animation and varying lightning remains an unsolved problem. I can't wait to see what Carmack and his team can come up with.