Module/theme synchronization checker

I do pretty much all my personal and professional Drupal work working with multisite installations. When deploying changes to a subsite, I normally rsync the local subsite directory with the remote one a la

rsync -uvaz --delete ~/Sites/drupal/sites/example.com/ abweb.us:/usr/local/www/sites/example.com/

That way, I'm only changing (and potentially screwing up) one site, instead of the entire multisite installation. (I don't use a VCS for this sort of thing, but it could be used similarly.) This works fairly well, but this strategy makes it more likely to accidentally cause a situation where the local and remote installations for a given site are out of synch;

1. I stumble across a cool module in the development of a subsite which I think would work well on more than just that site, so I put it in sites/all/modules locally and then enable it. When I rsync the site up, that module doesn't get copied over, so when the site is up on the live server, that module is missing. That fact may not be immediately apparent until I or someone else tries to use the functionality that module provides.

2. While developing a subsite, an update for one of the modules in sites/all/modules is released, so I update it locally. But when I put the site on the live server, I may not have updated the same module on the live server, so that breaks.

3. Or, the opposite of the above happens; a new version of a module is released while a site is live, so I update it directly on the server. Then I pull the site down to my local server to work on it a bit, but it still has the older version of that module installed.

So I propose a module (if something like it doesn't exist) which will check the paths, versions and enabled statuses of the things in the {system} table, and will complain loudly if that differs from the reality as is on the disk, as that would indicate that something is amiss.

One anticipated problem is determining when would be an appropriate time to make this check, since it's going to be somewhat disk-intensive. Perhaps it could be based on some relatively distinct variable of the PHP installation, such as the binary build date.