I very much appreciate their use of the word 'clone' instead of 'fork', and the focus on maintaining the idea of canonical repository and project:
User clones aren't forks, in the traditional sense,
where a fork has little intention to contribute back
to the original project. Rather, the entire purpose
of a user clone is to allow users to contribute to
projects without requiring official commit access
I was thinking of migrating some projects to github for this feature, but instead I think I'll just switch to Mercurial on Google Code.
Yes, this is a really important point. A lot of the "OMG git is so cool" early adopters seemed to go off on how great forking things is without making this critical distinction between a 'code' fork' and a 'project' fork. The first is simply a technical thing - the latter is a human thing.
Indiscriminately creating random project forks without contributing back is "bad open source citizenship".
Given that GitHub goes after Git users, and Google Code supports only Mercurial, I somewhat doubt it. I'd be more concerned for Bitbucket--and even there, even after the outages, Bitbucket is simply a vastly superior product to Google Code for 99% of users, in my opinion.