It seems that I will need to permanently define and export the arbitrary
variable 'V' in my shell environment in order to avoid confusion later
since I won't know how a build will behave until I type 'make'. That
leaves 25 more single-letter variables for my own use.

The rationale for keeping V was that users accustomed to the Linux build
system would not have to relearn. Maybe that is not such a good
rationale: those who build the kernel regularly are hardly the least
experienced users.

More significantly, GNU users are not restricted to the Linux kernel
or having any Linux experience at all. What feels normal for a Linux
user may be bizarre for a non-Linux user.

My opinion is that if this mode is optional that it should default to
"off" and that an action taken by the user (dot file, environment
variable, configure option) to declare a personal preference can be
used to trigger the Linux mode. Perhaps additional build modes would
be contributed in the future.

Hopefully it won't alter the behavior of other scripts or builds.

As I wrote off-list already, unless you use the 'silent-rules' option
for your packages, your code should be built as always.

This new m4 release is the first package I have seen with this
automake "Linux mode". I checked it for a special automake option and
did not find it so I assume that it was provided when m4 was manually
bootstrapped.

the default verbosity level that they are comfortable with. Something
like './configure --disable-silent-rules' to request the V=1 behavior?

It is wrong to change the default from the convention used by GNU
packages for at least 20 years. GNU packages should all build the
same by default. This year's package should build similar (by
default) to last-year's package.

Users of complex packages like my own would suffer severely if they
build in Linux mode by default. Users of simple stand-alone packages
like 'm4' are unlikely to suffer.