"Co-located branches" by convention

[Stephen J. Turnbull]

Ian Clatworthy writes:

 > dialog in Explorer offers 3 ways to init a branch. The "workspace model"
 > users choose between are:
 > 
 > * Feature branches
 > * Shared tree
 > * Plain branch

 > My weekend Explorer patch changes #2 to create this instead:
 > 
 > xxx/             (lw checkout pointing to trunk)
 >   .bzrbranches/  (treeless shared repo)[1]
 >     trunk/       (branch)

Does this have to be treeless?  When I use git, *most* of my work on a
project is done in a single working tree (let's say . is $PROJECT_HOME
for convenient notation) 'mainline'.  But if I need another tree, it's
quite cheap; I just do 'git clone --shared mainline feature'.  This is
identical to bazaar's stacked branch AFAICT, ie, all objects at clone
time are left in mainline's object database (ODB), and in feature git
looks first in feature's ODB, if not found in mainline's ODB.  New
objects in feature are stored in feature's ODB (and are invisible to
mainline).

Or maybe I've just answered my own question, which is: what do you do
when you really do want another tree?  I guess you can stack a branch
on any of xxx's branches by "bzr branch xxx/.bzrbranches/<branch>",
then, and put it anywhere you want to, eg as a sibling of xxx.

 > 3. Yes, using .bzrbranches isn't the same thing as true colocated
 >    branches, ones that bzr-git can use for referring to git branches.

So what are the workflows/scenarios that make a shared-tree project a
good idea?

Where that question is coming from: To me the value in git's colocated
branches is not so much the shared tree.  It's the ability to
efficiently traverse and edit the history of a multiheaded DAG.[1]
Efficient traversal is possible because by default you always have all
the commit objects (which constitute the nodes of the DAG) that are
reachable from any head of the DAG.  AFAICS, this is going to be true
in a bzr shared repo as well, although it would be nice to have a
compact language like git's for specifying relative revisions.  But
editing the DAG in bzr is still going to be hard.  (And maybe that's
the way it should be.  But see fn. [1]. :)

Footnotes: 
[1]  I don't want to argue the pros and cons of manipulating the DAG
in this thread, please.