Question: In large Libre Source software projects, versioned with Mercurial or similar DVCS tools, which of the following is considered to be more conventional:

1. Keeping the latest "stable" version of the software in the `default` branch. Tagging each release in `default` so you know which revision got packaged up as a download. Merging patches into `default` as soon as they are tested. Keeping new features, etc. in named branches to be merged into `default` on the next release.
2. Keeping each release in a named branch, or similar. Using `default` to keep bleeding-edge code that's only intended to be run by developers or the very foolhardy.

Or... is there some better pattern of workflow that it widely accepted?

Answer: 
I have fallen into the habit if using default in Mercurial and master in Git for the actual work, the bleeding edge, and using tags and branches for the releases. hgsubversion and Git-Svn seem to take this tack.
There's not a huge amount in it. If we're talking about just DEV & STABLE branches, which is default is mainly just a naming convention. I'd tend to have DEV as default, just because most work goes happens on the dev branch and if this is the default branch, it's less hassel.

Personally I prefer a named branch per release. Bugfixes can then go on those branches and be forward ported with relative ease to all releases after using `hg merge`. If you try to do the same with DEV and STABLE, you can only ever have one maintained release (the last one), or your stable branch starts growing branches and you end up with a (possibly less organised) version of the branch per release structure.