Well "journalling file systems" do come in many flavors and the Linux ones I've used just worked and never gave me any problems....
You've obviously never used ReiserFS 3. It was fast as hell, but it ate my fs twice. (Hans Reiser was the guy that killed his wife.) Other people had the same experience. The bug was hard to reproduce, and denied for years, until they found it.
But I take your point, ext 3 / 4 are journaled and very stable. (One protip is to add 'noatime' to your /etc/fstab so you don't turn reads int reads with a very small write. Almost nothing uses atime. Use some google fu for details.)
As for the other guys definition of journaled, as in letting you roll versions of files back, that's called 'a backup'.
Building that into a FS, probably with compression and (b)diffs wouldn't be that hard, but why do that when you can just keep the previous versions of the file around? (Space is cheap.) Journaled to most geeks pretty much means transaction accounting that does its best to ensure the FS always knows the state of all file transactions to ensure filesystem integrity.
Also, if you really need a file in the state it was in last Thursday, and don't save the previous versions, why not just put the file in a source control system? Most have GUIs, and will handle text and binary data. Munging that down into the FS layer seems like a good way to drown in your own metadata. Ie, a 20KB forum avatar that you've been slaving away on ends up having 1.5MB of your artistic improvisation as hidden metatdata non-portably embedded into the FS... Sounds like a nightmare. "Oops I copied this file from HistoryFS to a DVD and now all of the history is gone and I really did like the version from 6 iterations ago." Compare that to saving backups (.old1, .old2, etc.), or embedding the history in the file itself, or using source control, as opposed to in the filesystem.
