> dpkg distinguishes configuration of the package. In the first installation this is probably similar to rpm %post%. But with dpkg you have to chance to reconfigure later, to my understanding with rpm you don't have that.
While RPM packages can have interactive scripts in pre/post handlers, it is not allowed by most packaging guidelines so you rarely see it. Allowing for interactive packages complicates centralized management, such as with RedHat Network/Spacewalk, because there is no one to show the UI to. So the tools are there to work that way but most distros have chosen not to do so.
> zypper has [...]
We should probably differentiate between features in the package format and features in the higher level manager because zypper is also working with RPM packages behind the scenes.
> zypper has the concept of vendor change, in yum I have at least never hit it.
That could be useful, yum does show which repo its pulling a package from when it presents the install/upgrade job to you for approval so if you are familiar with the system you can spot an upgrade coming from an unintended
place but that's clearly not as good as explicitly pointing it out.
> Debian supports multi-arch now. Does anything like this exist in rpm?
That's more of a distro question than a package manager one, RPM doesn't have any problem with bi-arch hosts and doesn't require special package builds to support it as long as the different arch packages don't have file conflicts. This is different than dpkg bi-arch which required separate 32bit packages with a different name to not conflict with the native arch packages.
I don't know if there are any distro plans to transition to multi-arch.
> Debian seems to have more additional tools than the others
As someone else pointed out these tools also exist in RPM land but I find that the functionality is spread out over fewer different tools and the UI is more consistent, for example yum does the job of both apt-get and apt-cache.