I think that we are asking the impossible, to be universal, cover a large
number of fields, and fit all of this in a single name space witout conflicts.
With our current approach, to rename at least one of the program names, we make
Debian systems incompatible with outside documentation and scripts, and one of
the drawbacks of this approach is that there is no easy way to mechanically
discover and report to the user which programs have been renamed compared to
their original upstream distribution.
If we would tolerate conflicts, we would not support the parallel use of some
of our packages, but there would be the benefit that the package dependancy
graph could be parsed to report clusters of mutually-incompatible packages.
Often, these incompatibilities will not correspond to use cases, as there is an
obvious selection pressure upstream to avoid conflicts with other programs that
are directlyqused in combination with the upstream work.
A third solution is possible (and of course requires work), it would be to
implement namespaces in a similar way to the alternative system. Packages
competing for a program name would have the original upstream name in one
namespace, and leave it to the other package(s) in other namespaces.
Lastly, I just read Fedora's page about packaging conflicts, and noted
that among the recommendations, there is a suggestion to coordinate
with the other distributions in case of renaming.
Perhaps it would be usefult to see what they would think of renaming the ham
radio 'node' (it looks like currently the renamed program is the one of the
draft node.js package).
Tsurumi, Kanagawa, Japan