I have a few comments about the patch.

About the markup:
1) you can specify the default highlight (bash) once at the top of the file, and just use :: afterwards instead of .. code-block::;
2) the ```` used for some headers is inconsistent with the other files;
3) when you use NamedBranches, do you want to create a link? if so you should use :ref:`NamedBranches` and add a reference;

About the content:
1) you should make clear that bookmarks are local and they won't be included in the patch and/or affect the main repo;
2) we usually want a single diff for each issue -- you should show how to create a diff that includes all the changes related to issueA or issueB (this can be done easily with named branches, not sure about bookmarks);
3) hg ci --amend could be used to update existing changesets after a review (this will also solve the above problem);
4) it should be possible to use evolve instead of bookmarks, but evolve is currently still a work in progress, so I'm not sure is worth mentioning it yet;
5) you said that named branches, bookmarks, and queues are all branches types in Mercurial.  Can you add a source for that?  (I never heard of bookmarks and queues as branches, but they might be, and there are also non-named branches.  I just want to make sure that the terms are used correctly.);
6) when you mention :code:`hg log -G`, you should probably mention -L10 too, otherwise on the CPython repo the command will result in a graph with 90k+ changesets;
7) "Note that Mercurial doesn't have git's concept of staging, so all changes will be committed." <- To avoid committing there are different ways: a) leave the code uncommitted in the working copy (works with one or two unrelated issues, but doesn't scale well); b) save changes on a .diff and apply it when needed (what I usually do, scales well but it has a bit of overhead since you need to update/apply the diff); c) use mq; d) use evolve.  Mercurial also has the concept of phases (http://mercurial.selenic.com/wiki/Phases) that might be somewhat related, even though it affected committed changes (if you set a cs as secret it won't be pushed);
8) Trying to learn usual hg workflows might also be easier than trying to use a git-like workflow on mercurial, so you could suggest considering them too (I don't remember if we have anything about it in the devguide though).