Well, there is that bit where strings are all unicode, including all string literals and attribute names and all that. And the bit where open() will be different, although how different hasn't been decided yet. (Or rather, it hasn't been written down in code yet, and to me that means it hasn't been decided yet :)

What we need to do now is do the work on 3.0, and *then* (and a bit 'during', too) think about backward compatibility. As far as I can see, all the existing changes in the p3yk branch are upgrade-pathable: the int/long unification has long been done on the Python-visible side, 'except as' will make it into 2.6, print/exec as functions can be imported from the future, sys.intern/compile/etc can be made available in 2.6, classic slices are already on the way out, et cetera ad nauseam. The aim for 2.6 should be to have all the new features that 3.0 has, as well as full backward compatibility (albeit potentially with a few extra warnings, as any release might, but only for code that can be written sanely for 2.5-and-earlier as well.) The biggest hurdle will be the unicode/string unification and the I/O system (much bigger than the dict keys/values/items change), but since those haven't been implemented yet, it's rather pointless to talk about how to handle them in 2.6.

I expect you don't mean an actual import hook, but just a future import? Then sure, there is a chance. We'll have to see.