[racket] racket loader/vm detecting out-of-date cached compiled files

Is there any low-hanging fruit for making the command-line Racket detect 
more cases in which some of the compiled files are out-of-date?

Details...

I have run into a few instances of undetected out-of-date compiled 
Racket code a few times in the last year.

For example, today, after sys-admin did a code patch a production 
server, one part of the system gave this error when it was run:

     link: bad variable linkage; reference to a variable that has the 
wrong procedure or structure-type shape

My guess in this case is that either the code was not recompiled (though 
it should be when they do "make run" of the system), or that the compile 
was wrong because the file mtimes were wrong (such as might happen with 
SVN with clock skew, or with "tar").  This was with Racket 5.3.4.  
(Incidentally, this particular system has a large number of files and a 
somewhat funny dependency graph, possibly bigger than DrRacket's or any 
other core Racket code.  But my guess is that's not the cause of this 
problem.)

We also ran into out-of-date compiled files once before in production, 
in the last year.  Also involving some kind of update to the source files.

And I have run into out-of-date compiles in development of my open 
source code and personal apps, perhaps several times in recent years.  
Usually when using DrRacket (perhaps alternating between DrRacket and 
command-line "racket"), and probably when I was doing heavy syntax 
transformer work (especially when the module-file graph was messier, 
before submodules simplified that greatly).  Sometimes, it was obvious 
from things in error messages that an old compiled version of the code 
was being picked up from somewhere.

This is not a huge problem, but if there's some easy and efficient 
checks that could be added, that would be a win.  (Maybe there's already 
something like a file "stat" of source and corresponding compiled files, 
and some knowledge of the dependency graph that's consulted.  If that's 
bulletproof, then I wonder whether it would make sense to supplement the 
mtime checking with checking embedding timestamps embedded *within* the 
compiled files, consulted separately from the mtimes.  Though embedded 
timestamps might be significant work to do, when it's unclear whether 
bad mtimes are actually a problem for anyone in practice.)

Neil