Just as a tangent from the "proposal" at the end of the article: for my freelance writing, I use OmmWriter with plain/Markdown text stored in a git repo. It'd be really nice if the three things (the editor, the format, and the SCM) knew about one-another, though.
TextMate comes with support for Markdown and version control (Git, Subversion, etc). OS X only, although I've heard there is a wanna-be clone for Windows.
TextMate is horrible for writing prose. Unlike programming, where you perform discrete edits (like adding/refactoring a function, changing a constant value, etc.) changes to prose are continuous; ideally, every action (add character, backspace, move cursor) should be a separate "micro-commit." Similarly, syntax highlighting is almost guaranteed to screw up when one tries to write prose with it; I have yet to see a text format (HTML, Markdown, Mediawiki markup...) where you can paste in the current plaintext draft of your novel, and the second half of the book won't become highlighted entirely in green because it's "inside" an unpaired asterisk.
Ideally, a prose editor would be a minimalistic WYSIWYG editor, where each formatting option mapped to a feature of Markdown. The "document format" would, internally, be a Markdown document stored in a git repository—but actual Markdown text would be escaped if pasted into the editor itself, so this would just be an implementation detail (except if you tried to copy-and-paste from the editor to a plain textarea—then you'd get Markdown, which is better than losing formatting altogether.) The editor would auto-commit each and every change; undoing and then typing something else would create a branch.
Other people could work on a document/repo with you; the editors would P2P-send operational transformations when they knew that others had the same document open in the editor, with eventual consistency guaranteed by committing the changes to the repo asynchronously (where each user is committing their current view of the operationally-transformed state, so no git-level non-fast-forward merges are needed, unless the users are actually working on purposefully-made separate branches.)
