While this is a known behavior (actually a design feature I'm told), it's
very counter intuitive, and basically a headacke for package maintainers.
I scanned the bugzilla database, and apparently I'm the first one to log
this here, sorry if this is a dupe

While several people (Ted T'so, HJ Lu, and me) have had an Email discussion
with a few RH employees, Tim Powers recommended that I log this into
bugzilla, so here it is:
The current RPM behavior forces the RPM packager to explicitely handle
package upgrades differently than package uninstalls (by looking up $1).

What most people expect (third party package maintainers, and even some RH
employees who didn't seem to know about the RPM behavior), and what other
package tools like debian's do during an upgrade is:
- uninstall old package (run post-uninst)
- install new package (run post-inst)

Because RPM installs the new package first and then lets the old package
run its post-uninst, the old package may try to clean things that are going
to break the new package (which it can't even know about since the new
package didn't exist back then). If you think of a package that cleans
tables from a database, even if it's written to know about checking $1 for
an upgrade, it has no way to know which tables can be safely removed after
the new package has been installed
The other way around, the old package first removes everything (including
tables), and the new package installs what it needs. This way the old
package doesn't need to know what the new package does or needs, which is
the way it should be.

Considering the current state of RPM packages wrt this issue, I'd be very
surprised if making the switch would break anything, and if something
should break, I'm not sure that it'd be any worse than the current state
of affairs