Argh.  This export-to-shell-function change is the gift that keeps on giving.

I guess the best thing to do is, rather than expanding a recursive variable to the empty string, we expand it to its contents without trying to further expand it to avoid the recursion.

That could be weird.  Definitely need to think carefully about this, probably after I have my tea.

Tried to use `make` from today's git (commit 7d484017077089ac2642b89da8984ca46a07323d [SV 63016] Don't fail exporting to $(shell ...)) and observed build failure on autoconf:

build flags: -j16 -l16 SHELL=bash
bash: line 1: env: command not found
make  all-am
bash: line 1: make: command not found
make: *** [Makefile:928: all] Error 127

The build failure happens because (I think) autoconf uses the following trick:

cfg.mk:export PATH = $(shell echo "`pwd`/tests:$$PATH")

Comparing behaviour from `make` a few months ago:

$ make --version
GNU Make 4.3.90.20220619

$ printf 'export PATH = $(shell echo $$PWD:$$PATH)'"\n"'all:; echo $$PATH' | make -f -
echo $PATH
/tmp:/run/current-system/sw/bin

Path is prepended to existing one, ok.

And the today's one:

$ ./make --version
GNU Make 4.3.90.20220909
$ printf 'export PATH = $(shell echo $$PWD:$$PATH)'"\n"'all:; echo $$PATH' | ./make -f -
echo $PATH
make: sh: No such file or directory
make: sh: No such file or directory
make: *** [/tmp/GmYdo0my:2: all] Error 127

If we use `:=` then it works as expected:

$ printf 'export PATH := $(shell echo $$PWD:$$PATH)'"\n"'all:; echo $$PATH' | ./make -f -
echo $PATH
/tmp:/run/current-system/sw/bin

In theory it should be easy to adapt `autoconf`s build system. Filing a bug to make sure it's an intended change and not an unexpected regression.