Something struck me while implementing the predecessor list logic in commit that makes the answer fairly obvious: entities should definitely name the branch and version under which they were first committed.
My original reluctance had to do with the fact that you could have many branch versions including the same entity, because the entity gets carried forward until it is modified again. In a straight-line branch this causes no confusion; the back pointer merely names the version on the current branch in which the entity was introduced.
The reason I wanted to avoid the back pointer was that confusion might arise after a merge. Given a merge resulting from two lines of development A and B, you'ld suddenly have objects whose last modification was in B and objects whose last modification was in A. In time, this would make the merge algorithm behavior fairly hard to understand, because the closes common ancestor would turn out to be something on some long-forgotten branch.
What I failed to consider is that if the object has been modified on either branch, the merge needs to generate a new entity, because the predecessor list needs to be updated.
So a question for Josh (and John, and anybody else who feels inclined to chip in):
Assume that lines of development A and B derive from a common ancestor, and that we are now merging them back together. For a given entity X, it seems to me that the following possibilities exist (I'm ignoring the cases where one or the other is missing).
shap