The compression issues are somewhat subtle, so let me try another way of describing this. We want to support the mental model that the "real" collection consists of files like /netlib/eispack/rg.f and everything else is transport mechanism that, ideally, is transparent to the end user but thrifty in use of network resources.
The best approximation I can give today is to publish the "real" uncompressed filename, and give simple algorithmic rules for how to add prefixes (like http://netlib.bell-labs.com) and suffixes (like .gz) that transports should apply. The current rule is: add .gz unless the real filename has a suffix listed in /netlib/crc/net/compressed.
File dates, seen for example in directory listings from the ftp server and in the /netlib/crc/ checksum files, are modification dates of the intrinsic file contents, and are not affected by compression.
Consistent application of this rule implies that small files are compressed when they don't really need to be. Because this is such a burden on people using nonconforming Web browsers, we make a special exception for .html files and provide those in both compressed and uncompressed form. This requires some care adjusting internal links in .html files, of course, but that is done inside the netlib server.
The ftp server at netlib.bell-labs.com has an additional feature of creating, on the fly, tar files of entire netlib subdirectories. This tar file does not get any additional compression, because the files inside are already compressed. (Microsoft later adopted the same approach, but a proprietary format, in their .cab "cabinet" files.)
Broken browsers that violate the long-standing HTTP specification do you a disservice by needlessly slowing transfers by a factor of 2 to 4. If you get stuck with one of these buggy browsers and have no other way to get your files, try webget which you can get in (uncompressed) email via
mail netlib@research.bell-labs.com
send access/webget.c