Sandro, I find your patch is really a regression:

-* Then clone it to create another local repository which is then used to
-  checkout branch 3.2::
+* Then clone it to create another local repository for the 3.2 branch::
 
This makes the terminology ambiguous. The old sentence is worded exaclty like that, because it is important to make the distinction between repository and working copy contents. You do *not* create a repository for a single branch; instead you clone the *whole* repository and then checkout the desired branch. If you don't distinguish the concepts clearly, hg beginners will get a wrong idea of what happens.

+  (this command is equivalent to those used to create a local 3.2 branch, but
+  it's more concise.)

This is wrong too. You *don't* create a local 3.2 branch, you checkout the existing 3.2 branch. This is totally different.

+you have a patch that should also be applied to Python 3.2. To properly port
+the patch to both versions of Python, you should first apply the patch to
+Python 3.2::

Please replace "apply the patch to Python 3.2" with "apply the patch to the 3.2 branch".

+With the patch now committed, you want to merge the patch up into Python 3.3.

a.k.a in the default branch.

+This will push changes in both the Python 3.2 and Python 3.3 branches to
+hg.python.org.

I would prefer "the 3.2 and default branches".

+The import is
+possible because changesets are unique per repository, and so in ``py2.7`` you
+also have all of those of the other branches.

I find the wording of this sentence confusing and I don't think it brings any useful information.
(yes, changeset ids are unique, this is a property of Mercurial and doesn't deserve mentioning specifically here)