Have to agree I'd expect branches to be synchronized. I suppose I'm thinking of cases where subversion is the master. If you had limited commit access to a subversion repo or were cloning it and primarily tracking upstream changes you'd want it to be optional and be able to normally reserve branching for hg-only.
Anyways, aren't we just talking about having a property on csets for whether subversion knows the branch? So have an 'hg svn branch' command that can be used same as hg branch, and additionally sets the subversion-knows flag. Don't know what --unset would mean after it had gone out though, or how this interacts more generally with actual subversion branches / deleting same.
Note that while I'm interested in the tagging from hg feature, I personally lack motivation on this issue (creating branches). I might get to it eventually, but someone motivated enough to provide a patch will definitely beat me to that...
My use case: external contractor hired to create feature-x
My setup: SVN <-> svn-hg
I create a feature-x branch in svn-hg, put all of my code in it, merge back to default, and then push. The result in SVN is a nicely branched feature that is then merged back to the trunk. I may not even merge back to default to give the client the chance to review the work before they choose to merge.