Solution: divert the usr/share/autofs/conffiles/auto.master file as well, either leaving it empty or making it a symlink to /etc/site as well.Doing both seems to be sufficient to preserve the local changes.
The ucf system should be turned off for files that are provided by a -config package, and turned back on if the -config package is removed.
The -config package would need to have encoded inside it the same ucf command that took over management in the first place.
If dlocate /etc/filename doesn't locate a package, there's a good chance the configuration file is a debconf-generated file.
In the ideal case, there are values you can put in the debconf system that will generate the correct file.
Roughly 5% of Debian packages use the debconf database and custom scripts using that data to generate configuration files.
These scripts are located in /var/lib/dpkg/info/*.config. While there aren't a large number of these packages, they tend to be the most critical and important packages, and each one is a custom script that must be understood before you take over control of its configuration file.This avoids making the replacement file also a conffile.There are complex interaction cases where a package may be removed but its configuration files remain on the system.Some configuration files may need to be taken over at specific stages of bootup, but left unmodified until then.If there is no good mechanism otherwise to disable a package from rewriting a configuration file, or if it has to be returned to unmodified state before the next boot, a read-only bind mount in a bootup script may be the only way.The problems arise later when there are updates to the packaged systems.