That's what I would do.

That would solve all the updating issues, bu where do you draw the line?

When the drawbacks outweigh the benefits, you copy and paste what you need and start a new project.

If I put the instance scripts and templates in the same tag as the app module, I can't install the app module on another machine without installing the instance, which is not desired.

Make a config file that says which instance to use. Install all the code, even if you only need 5% of it on a specific machine. Anything else will lead to dependency nightmares.

Okay, we've looked at that model. The problem was trying to keep development from clogging up production. Quite often we'll start on development and get pulled off onto other projects, leaving code incomplete, sometimes returned to, sometimes never returned to.

Do that unfinished work on a branch. Use a separate branch for each project. Merge the trunk to the branches periodically. Merge the branch back to trunk when you are done.

Here I'm missing details again. If we're checking out the entire codebase, are we running every bit of test code we have? How do we do the install process so that only the changed bits of code are tested on the new machine?

Since you're describing a codebase with lots of reuse, you have no choice but to test it all, to make sure you didn't break an older app. Don't try to test "just the changed bits." Regression testing is about testing it all.

(Anyone with advice on what to do with the Windows designer who edits our templates would be welcome, since he can't test his edits on his machine.)

In most cases, it should be possible to make your code run on Windows. If it really isn't, the best approach is to have a test server (web server, not a whole machine) dedicated to your designer, with the templates on a samba share that he writes his files to. That's nearly as transparent for him as running it on his own machine.

Really, I'm not disagreeing with good practices, I'm just trying to figure out how to IMPLEMENT them.

You need to explain to the people who could finance the purchase of test servers, load-balancers, etc. what the risks are that they are taking. They might prefer to have some bugs and some downtime in exchange for saving $10K on hardware, but then again they might not.