Ah, but it seems to me that this may break portability, won't it?
Developers who use this would create project dists that won't build out of the
box on systems without versioned auto* scripts, after say configure.ac or
Makefile.am has been touched.
Perhaps a better solution to this, would be to use alternatives to choose which
autoconf and automake version is the default?

Broken Portability
==================
Yes, it breaks the portability -- but IMHO this is not very important, because:
- after calling 'aclocal' the RH-specific changes are reverted
- changing the configure.ac or Makefile.am is a uncommon action for end-users,
the developer knows what he has to do and distributors are rebuilding these
files by calling auto* explicitly
- other people than these above will get a message from 'missing' telling that
the program was not found and can call auto* explicitly
(- configure.ac without AM_MAINTAINER_MODE are erroneous and a pain for the
end-user)
Alternatives
============
I do not see much profit in the alternative-system (not all Debian-stuff makes
sense). 'alternatives' makes system-wide settings but autoconf-2.13 vs.
autoconf-2.5 is a per-user decision.
Such an user-decision can be done already by setting environment variables, but
it is bloat because each AUTO* program requires such a variable.
Probably, you will run into problems with the slave-links of automake also
(Version 1.4 contains 4 info-files, version 1.5 5 ones, but alternatives
requires the same count of slave links).
Other ways
==========
The best solution would be if autoconf/automake are writing the needed
program-names into configure and the Makefile.am.
Another hac^Wfix would be the modification of ./missing in a way like:
| case "$1" in
| --run)
| # Try to run requested program, and just exit if it succeeds.
| run=
| shift
|- "$@" && exit 0
|+ prog="$1"
|+ shift
|+ case "$prog" in
|+ autoconf)
|+ for flavor in "-2.53" ""; do
|+ "$prog$flavor" "$@" && exit 0
|+ done;;
|+ automake)
|+ for flavor in "-1.6" "-1.5" ""; do
|+ "$prog$flavor" "$@" && exit 0
|+ done;;
|+ *) "$prog" "$@" && exit 0;;
|+ esac
|+ set -- "$prog" "$@"
| ;;
|esac

This is becoming something of an issue, because e.g. GNOME 2.0 prereleases won't
build with an "older" autoconf or automake. Is there any way autoconf, automake
and aclocal can be updated without breaking "compatability" (strictly, this is a
source issue rather than an ABI one, isn't it) ?

billc, in the mean time you can use
make AUTOCONF=autoconf-2.53 AUTOMAKE=automake-1.5 \
ACLOCAL=aclocal-1.5
etc.
Enrico, what is the reason for the
set -- "$prog" "$@"
in your suggested change to missing?

Because I shift'ed the first argument out of $@
| prog="$1"
| shift
and want to keep the rest of 'missing' working as before, I restore $@ with the
'set -- ...' statement.
But as indicated above already, I consider the modification if 'missing' with
this hardcoded version-numbers as a dirty hack. The "correct" way will be the
modification of 'autoconf' so that it codes its version-number somewhere into
configure.
The 'automake' case-clause is not needed for 'automake' >= 1.6 because it
encodes its version-info already.

While I agree that the missing patch is a bit of a hack, it is quite
flexible and making configure understanding versioning will create
more portability problems I would say. So I think the above is a
reasonable compromise.