Is the merge step really necessary? Let people create their own branches from whatever starting point they like best, and let all branches/versions co-exist. It's not a piece of software you're developing after all; there may be many different viable paths, and darwinism can take care of selecting the winners via attrition of paths. I realize things can get fairly chaotic. The number of forks or sub-branches of a given version can act as a good crowd-sourced indication of popular snapshots.
I actually built exactly this into a web app, and tested it with a few dozen authors from a local writing club. Writers could add/branch the book at the paragraph level. Readers could open up the book at the beginning or at any arbitrary node, and there was some magic that would automatically pick the longest and/or most interesting branch to "fill" the book as you read. Readers could of course also browse any other branch. This was surprisingly easy to build with Neo4j as the data store.
I never did anything more with it because it was obviously at its best with a small number of users, who all happened to be meeting in person regularly; I had no ideas about how to scale up that experience to the wider net. Still, it was a ton of fun while it lasted.
That's really cool! I think one way to make the experiment scalable is to add a social network overlay, where people can "follow" those other authors they're watching, so they can build off their contributions.
We've been using these ideas in the classroom as well: post an assignment where multiple solutions are possible, and let students build off each other's contributions (implemented as a Moodle plugin). I want to expand this into note-taking and wikis in MOOCs.
Disclaimer: we've been toying with this idea for a while, and here's a paper (and tool) that came out of it: http://onlinelibrary.wiley.com/doi/10.1002/cpe.3420/abstract