> Many of the inconsistencies that Recon found and fsck didn't were changes to unallocated data, which are not important from a consistency standpoint, but still should not be changed in a correctly operating filesystem.
That may be true of ext3, but in general there are a few reasons why one might want to write to space which has not been allocated *on disk*. Atomic updates come to mind: reserve space in memory, write the new data, and finally--after the data has been committed--reserve it on disk and update the metadata. Online defragmentation or resizing could be implemented this way as well. Unallocated data is "don't care"; it shouldn't be a problem to change it even if the reason for the change is not yet apparent.
This also seems to introduce a second point of failure; the system can cease to function due to a filesystem bug, as before, or due to a bug in Recon which unnecessarily blocks access to the filesystem. That risk would have to be weighed against the cost of filesystem corruption in the absence of Recon, of course.