Reading this thread has given me an idea. Imagine three servers, called Dev, Stage, and Prod. Dev is where the code magic happens, and where Heyrocker's deploy.module would be installed to push changes up to Stage.

Stage is where the QA happens, but not where content is added. All content changes have to happen to the Prod server, and here's why.

# Content flows downhill
Users and admins create content on Prod. A brand new, never-before-thought-of module utilizes NodeAPI to create duplicate content on Stage and/or Dev whenever a node is created or edited on Prod. Thus, 100% of content is added (or deleted) to Prod and flows downhill. Node ID's remain sequential and perfectly in sync.

# Code flows uphill.
All changes to code, including views and content types happens on Dev, and is pushed to Stage for QA and testing, and then onto Prod for final deployment. Any content type changes that occur will be reflected on Stage first before showing up on the live site, so they can be tested and tweaked. Thus, Stage becomes both a clearinghouse for new functionality *and* a mirrored copy of the Prod server, but its tweakable until showtime.

# Keeping track of the /files
An rsync over SSH would need to be set up to keep the files directories in sync. Prod's /files need to be rcyned by Stage, and Stage's /files need to be rsynced by Dev. In this manner, and on a cron of say 10 minutes, a shell script is executed. Your Dev box's referenced /files will never be more than ten minutes later than your Prod box's referenced /files, even though the nodes themselves will exist already because they were created at the same instant on both Stage and Dev.