The only thing I would question, Greg, is that a Recover normally does *NOT produce this recover table occurrence. So when it DOES appear, it indicates to me that it has found something (at least) questionable. And when Recover finds something questionable, it can mark those areas as bad even if they aren't (meaning it takes aggressive action to scrub it and the scrub itself can damage). And this is why files should not be used after a Recover (even if no Recover Library is produced).
I would consider the file damaged if I saw Recover Library table appear. That does not mean I'd trash the file immediately but it would be high on my list to rebuild it as quickly as possible (immediately if I have good backup). The same holds true if I see a Recover log appear. It usually indicates the files was improperly closed and that can damage a file.
Now in 13 with Web Direct, a recover log is created when you upload the file (which drives me nuts) so that is the only exception where a recover log wouldn't cause me to dump a file and step back. Folks seem to forget that the pristine nature of the files in a solution are CRITICAL. It is very difficult to rebuild a file. It is very simple to hold oneself to extremely high standards of file protection. I am a LION not a cat when it comes to protecting files. Once damaged, they can cause problems until the end of time.
Added --- * you can test whether Recover Library is generated by creating a new file with a few fields, close it then run recover on it. Really good files do not produce this Recovered Library table occurrence - only files with damage. At least this is my observation.