I've given examples where installers do the wrong thing.

I think the heart of your problem is revealed when you refer to "the installer". There are many installers, for many products, from many vendors. Some vendors are more conscientious than others, some are less so.

Apple is among the more conscientious vendors, but as I've pointed out even the App Store will sometimes be overly aggressive about trying to update files that are not on the boot volume. Since I want my backup volume to reflect what was on disk before the update, that's unsatisfactory. Never mind why it sometimes does that; the point is, it sometimes does do that.

Even if you focus on just Apple's Installer.app, you have to keep in mind that even that app doesn't always behave the same. Any vendor can use the PackageMaker.app (typically installed as part of Xcode, in <xcode_directory>/Applications/Utilities) to create an installer package. An installer package can be thought of as a "document" for Installer.app. During its creation, the vendor can customize the installation process in many ways. (Examples: there are checkboxes for whether the payload can be installed on only the boot volume, whether the user has to agree to a EULA before installation, whether an admin password is required, whether a prior version has to be present, etc., and options for minimimum OS, hardware requirements, which components to install by default, where they are installed by default and whether the user can customize the installation location, and many others.)

In case the pre-defined options are insufficient, the package can also include scripts to be run pre-flight, pre-install, and post-install. The most common use for install scripts is to do things that cannot be described as "install these files/folders", but in fact those scripts can do pretty much anything. For example, they can change permissions on existing items (Remember when all of a sudden "group:everyone deny delete" ACLs suddenly appeared on major folders?), they can change visibility (Like, making /Users/*/Library invisible.), they can add users and groups (the Xcode installer creates the _developer group), edit package receipts in an attempt to make Repair Permissions spout fewer spurious messages (I sure wish they'd eventually get that right), verify package signatures, delete incompatible software, edit your shell startup scripts, and on and on.

The sheer flexibility built into PackageMaker.app means that, even for packages installed by Installer.app, there is no single behavior that describes what "the installer" must always do. It does whatever that particular package tells it to do.

And Installer.app is far from the only installer out there. The VISE installer is rarer than it used to be, but still crops up from time to time, and vendors are free to use others or roll their own. As I recall, many of the "software bundles" use their own installer. Adobe Flash Player uses its own custom installer. (Other Adobe products may, too, but that's the only one I have installed.)


You want me to "tell [us] so that we would be more cautious in dealing with updates", but I've already given you something very simple that is completely safe for updates and installs: just unmount your backup volume after you finish backing up to it.

You should be doing that anyway. Your backup volume only needs to be mounted while you're backing up to it or restoring from it. At all other times, prudence dictates that it should be unmounted, for its own protection. It's not just installers and updaters that may grab it at inappropriate times: "open with..." will suggest applications on the backup, and some applications try to update files on their volume. Once you run an application from the backup volume, LaunchServices thinks that's the preferred copy. Spotlight will find items on all mounted volumes, so documents you find via Spotlight may save changes in a place where they'll be lost the next time you back up. Merely touching an alias on the backup may cause the alias to auto-update.

In short, you don't want to leave your backup mounted anyway. Why postpone the unmount? (I also turn it off, so it won't remount automatically on the next restart.)