This morning at IIW Dick Hardt presented his vision for solving the issue whereby a user is dependent on his OpenID provider being up and non-evil. He's posted a demo.
The basic principle is that a user is identified by a triple of (url1, url2, keypair) rather than by a single URL, and can update any one of these three tokens when authenticating to pivot to a different identifier and thus provider. The two URLs and the keypair are linked together via hidden metadata at the URLs allowing the RP to verify that they are valid. Revoking one of the URLs and replacing it with another just requires updating that hidden metadata to create the new two-way linkage. You can also change the keypair as long as you update the linkage at the two URLs. Another change is that the request can now go directly from the browser to the OP rather than via a redirect at the RP, thus improving performance and making it easier to develop client-side "providers" in the form of browser plugins.
This seems like a promising approach, but it's quite a radical change from the way that OpenID currently operates. I think we'd need a good migration story so as not to leave all of the existing adopters out to dry. I suspect that if we did go this route we'll ultimately need to find a compromise between the two approaches. It could also be argued that we should wait and let OpenID 2 finish bedding in before making yet another complete rewrite; while OpenID 2 does have its problems, I believe that we should try to extend it as far as possible without replacing OpenID 2 already, especially after how long OpenID 2 itself took to finalize.