Sorry - I want my version control system to be really, really good at being a version control system, not at being a system to train other software developers.
If you're an experienced developer, you should be able to pick up the static source code and figure it out how it was engineered. If you're not as experienced, you will learn through doing (not reading) and perhaps by working side-by-side with a more experienced developer.
If you're a really good developer it is true you might not get a whole lot of value from watching a playback. If you're a really good developer, though, it is difficult to take the time and effort to teach all of your less experienced team members about what you have learned while writing the code and to become better programmers. These playbacks offer a relatively efficient way of letting good developers teach once and have many developers learn.
If you're not a really good developer the question is how do you become one? It is possible to learn the hard way by doing (like you suggested), but it is painful. A playback is not just watching the code as it was developed but it is listening to the developer explain why they are doing things. My hypothesis is this will make it easier for people to become better.
I always wanted more dynamic commenting which some of the fisheye/github tools already do. For instance being able to have a discussion about a line of code. Not necessarily a code review, but more like explaining the code with pro/con discussion if necessary. It is a bit troublesome to implement you always get snapshots of code, so how to track lines. Plasticscm seemed interesting, http://www.plasticscm.com/gallery.aspx, but I think they are aiming at the Microsoft crowd, git is pretty firmly entrenched otherwise. Looks like they tried to learn lessons from git and it's success.
There really may be some learnings worth extracting from a long-term source repository, but I think the cognitive overhead of looking at years of old commits competes with being able to focus on the code in front of you.
Can't help but feel this would produce an epicly poor signal to noise ratio.... No one cares about someone's keystrokes as thats attacking the wrong level in information hierarchy. Overall seems like a self indulgent academic effort (nothing wrong with that per-se but the real world doesn't need it). It's interesting to compare relative interest in this to Light table mentioned a few days ago
All keystrokes are recorded but that is not the main form of documentation created. A developer creates a playback of only the 'interesting parts' of the code and provides a narrative about why they think it is interesting.
Then, when someone looks at some unfamiliar code they can search to see if there is a 'story' about that bit of code. The code and the narrative playback side by side. The noise can efficiently be bypassed.
To me a playback system does not provide anything useful. Never have i found it insightful watching people write code. In fact, most of the insightful stuff comes not from the code itself, but the design and brainstorming process that went on before even a single line was written.
That information can and should be recorded somewhere. The most natural place (I think) for it to be recorded is along side the code where the insights are applicable. The tool was built to allow developers to create these 'stories'.
What I want: an undo graph, like vim's undo tree with merges. I want it visualized and browsable, maybe with real time sharing. It needs powerful git-like tools for squash, rebase, etc so you can make neat changesets to publish for review.
If you're an experienced developer, you should be able to pick up the static source code and figure it out how it was engineered. If you're not as experienced, you will learn through doing (not reading) and perhaps by working side-by-side with a more experienced developer.