That's not really a problem with Versions, though - that's a problem with AutoSave, and it shows exactly that Versions is good, because AutoSave without something like Versions is a really bad idea.
No, it's a problem with Versions. Autosave worked fine in 10.6 and was perfectly safe.
In Snow Leopard, auto-saved files would show up as a separate file entirely. If the file already exists on the disk drive, then you'd get an autosaved temporary file in the same directory as the one you're currently editing. Once you saved the file, that file would replace the one on-disk. If you quit, the autosaved file was erased, and the original was left untouched. If the program crashed, both files were left- the autosaved version, and the original. NEVER under ANY circumstances would ANY program ever overwrite the original file without user confirmation (saving that file).
In Lion, "Versions" insists on forcing the programs that are compatible with it to save every so often without user permission or action. Apple assumed that Versions would be infallible, so Versions (or rather, by using Versions) always overwrites the original file automatically every so often. It'll also save a file the moment you press CMD-Q or exit the application.
This is an extremely dangerous and unexpected way of handling file saving when you're operating in a situation where Versions doesn't work 100%- like on a network share or a non-HFS+ volume.
As I said before, this is a feature that belongs at the filesystem level where it can be extended to ALL applications WITHOUT using a dedicated or different API. Then, if you're ever dealing with a network share- programs just continue to work the way they always do. It makes no difference to them because they don't need to know how the underlying filesystem operates- they just need to read and write data. If you're running locally, the filesystem gives you the benefits of versioning support. If you're working on a NAS, then unless your file sharing protocols support versioning (I'd presume through some sort of "metadata" tunnel) and the remote FS supports it too, nothing happens. Things continue to work as expected.
There's no reason why Apple couldn't have baked it into a proper filesystem, then gave us access to viewing and navigating the files through a Quicklook powered UI (apart from your application). Browse through time, pick a file, and launch the application that it belongs to. If they'd have done things like that- every single application on the Mac would have instantly supported versioning without being recompiled. Things like Photoshop would gain the benefits of Versioning (if you wanted it) without actually having to know about it. From the point of view of the application, it's still saving data as usual. But the file system is keeping track of changes and making sure that you're never actually overwriting (losing) information.
Oh wait, I misread that. That does sound really useful. Then I wouldn't have to use Terminal or launch a Finder instance with root privileges in order to find out how much space all versions take up.
Be careful with this. If you erase Versions' storage directory to reclaim space (".DocumentRevisions-v100" in the root of the drive) , you will cripple Versions. For some reason, manually removing that folder does NOT guarantee that the system will properly recreate it. I've heard that you have to go and repair the entire disk in the Recovery HD (not repair permissions, repair disk) in order to have it recreated properly. Otherwise your Versions applications will stop working or otherwise malfunction. Just another pitfall of this wonderful technology.
-SC