This is a regression caused by commit
<https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=713d9822bbfb2923115065efaefed34a0113f8a1>,
"Fix timing bug on high-speed builds".  That commit changed autom4te's logic for deciding whether its output file is newer than its cache file: if their modification times are equal, the output is considered out of date.  Since both files are created in quick succession, on file systems with coarse timestamps (1 or 2s resolution), it is very easy for their modification times to be equal.

For 2.72 I'm going to make the test suite adjust the modification time of the file that's supposed to be newer, but I'm also going to leave this bug open, because autom4te ought to be able to ensure that the cache file is always observed to be older than the output.

Observed by me on at least x86_64-netbsd9 and sparc64-solaris10: the "autoconf: forbidden tokens, basic" test fails because the second invocation of autoconf prints the same "possibly undefined token" error messages as the first invocation, contrary to the test's expectations.  This is probably more fallout from the sub-second timestamp changes: the second invocation is supposed to pull 'configure' from cache and not re-run M4.  Unfortunately, the second invocation of autoconf clobbers the mtime of all the files involved, making it difficult to figure out exactly what went wrong after the fact.