Install binaries into /bin, /sbin, /usr/bin and /usr/sbin, interactions with --prefix and DESTDIR

Essentially, the distinction between the / and the /usr hierarchies is not and should not lie in the hands of the packages' upstream maintainer (read: Is not your responsibility). Since / should only contain files necessary for booting and making /usr available, it is an administrative decision what goes to /. For installations from source, this decision is made by the installer, and for distributions, by the package maintainer.

For a rationale, suppose someone is trying to build a chroot environment. The distinction between /usr and / is meaningless in the environment, and will not be made. All prefixes are set to /foo/bar/chroot, and any configure script messing with $prefix is likely to induce strange behaviour. The same arguments goes for scripts like the Debian packaging helpers, which rely on the usual $prefix semantics to work.

The cleanest solution is therefore the bash-4.1 solution. You have basically two clean options: Split your package into boot-critical and non-boot-critical parts, or let your configure script offer an alternative prefix for the boot-critical parts, which is set by default to /, leaving $prefix as /usr.

There are two different levels to this question, and your questions all seem to apply to the second meaning (the binary package generated by your *.spec file, or debian/rules, or a *.pkg file.) As far as the autotools are concerned, you DO NOT CARE. You must not attempt to specify a default prefix other than /usr/local in your configure.ac. Specifying where things should be installed is done in the binary package control files, and NOT in configure.ac. The source distribution using the autoconf generated configure script should install in /usr/local by default, and anything else is a packaging error.

If you want to have a source distribution that the user can use to install easily in a particular location on a particular platform, it would be acceptable to include a script in the tarball that does so. For example, you might include a build script that looks something like:

#!/bin/sh

case $1 in
foo) args='--prefix=/usr --bindir=/bin --sysconfdir=/etc';;
bar) args='--prefix=/opt';;
*) args=;;
esac
$(dirname $0)/configure $args &&
make &&
make install

which would specify default arguments to configure for the 'foo' and 'bar' platforms, but it really sounds like your questions are about control files for binary packages.