If you've created many packages with the Solaris package manager, these will seem pretty familiar to you.
The basic idea is that as well as just listing the files contained within a package, you place each one in a different class as well or leave them in the default class.
none /usr/bin/dpkg none /usr/bin/dpkg-deb doc /usr/share/man1/dpkg-deb.1.gz doc /usr/share/man8/dpkg.8.gz conf /etc/dpkg/origins/debian
When packages are installed or upgraded they are unpacked and files are put in place by calling the appropriate class install script. When packages are removed or files are outdated they are removed by calling the appropriate class remove script.
The script can an executable that takes a list of filenames or can be implemented internally in dpkg or as a .so plugin. They can be overriden at a global-level by registering them through a configuration file, or overriden at the package-level to provide its own handling for a particular class.
Dpkg will provide handling for at least two classes by default: the first is the default "none" class which will simply copy files into the correct place; the second is the "conf" class that will be an enhanced version of the existing configuration file handling.
This flexible system would allow a package to be installed and improve dpkg's handling of conffiles, you could feasibly have a GNOME 3-way diff frontend for example. It also allows SELinux-enabled systems to override the default class to update the various contexts during installation; it could also provide a whole additional set of classes for SELinux-magic should that be required.
Packages can also use this to provide special handling for files that need it; it could place a particular configuration file in a class and provide an action script that updates the file by parsing the old one and updating any non-overriden values, for example.
This could work well with RelocatablePackages.