This is a bit hard to explain concisely, but here goes.

Doing an "update-alternatives --install /some/where foo /my/foo ..."
when such an alternative already exists (for same values of
/some/where, foo, and /my/foo), but with _different_ set of --slave
names, the "orphaned" (ie. present in the first update-alternatives
--install, but omitted in the second) slaves are not removed.  After
doing this, the only way to clean them up is to manually remove the
orphaned slave links (as well as files from /etc/alternatives) which
are no longer slaves of anything; even "update-alternatives --remove
foo /my/foo" does not delete them.  (The bug is in --install, not
--remove, though.)

The Debian version of update-alternatives does not have this bug.  It
also has the improvement over the Fedora Core version that doing an
"update-alternatives --display foo" when there are no alternatives for
foo prints "No alternatives for foo.", whereas the FC version prints
nothing.

I will attach annotated typescripts from a FC2 box and a Debian box;
the FC one shows the current buggy behaviour, and the Debian one the
expected, correct one.

It would be very nice to have this fixed (as well as add the "No
alternatives for foo." message added) at least for FC3, but preferably
also errata for earlier versions as well; we in JPackage are currently
being bitten by this.  Essentially, the bug makes it very hard for
packagers to achieve correct behaviour when some slave alternatives
need to be removed on package upgrades.