It provides (safe) mutable history for local changes (the VCS tracks what is safe and what isn't), and a way to still be able to collaborate on changes without "surprising" the people who pull from you.
E.g.: http://draketo.de/light/english/mercurial/hg-evolve-2013-01-...
We had some discussions as far back as mid-2010, at the time the feature was called LiquidHg. The first step was phase (differentiate between changeset states), and now it's evolve (make it flow).
I always wished that darcs was usable "in the real world", as the concept of composability is very appealing. Perhaps there is a compromise to be reached here (local patchs with key sequence points?)
I'm sure there's an answer to that question, but I'm equally certain it's not the only question. It's not that git solves all this stuff perfectly, or that it does it in the best way possible, it's that lots of problems in SCM are human communication issues that simply cannot be solved by software. One of git's virtues is that it knows its own limitations.
That's what I like about Mercurial (also those days I use git more than I use mercurial due to $WORK).
The extension is experimental, and I'm not sure how many guarantees are given wrt stability (probably best effort).
Now the extension is in the process of getting moved into core (where the behaviour, protocol, file formats will be frozen).
The text looked to me like one could extract all the commands, run them and check their output against the embedded reference output automatically. I don't know, it had such a rigid structure.
On a second look, the output contains timestamps, so what looks like shell output is probably only shell output the author has copied once into their text.