This is fixed now in two different ways:

First, the jobserver has been reworked to use a named pipe instead of an anonymous pipe.  This means that any sub-make can open and use the pipe without having to have file descriptors left open.

Second, on systems where we can't use a named pipe we'll add an extra argument disabling the jobserver to MAKEFLAGS to ensure that makes invoked by shell won't try to use it.

I don't think so:

martind@sirius:~/tmp/D150109$ cat 2.make
makeprog := $(MAKE)
OUTPUT := $(shell env | grep MAKEFLAGS 1>&2; $(makeprog) -f 3.make)
default:; @true
martind@sirius:~/tmp/D150109$ ~/download/make/make -j2
/home/martind/download/make/make -f 2.make
make[1]: Entering directory '/home/martind/tmp/D150109'
MAKEFLAGS= -j2 --jobserver-auth=3,4
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Leaving directory '/home/martind/tmp/D150109'
martind@sirius:~/tmp/D150109$

This warning:

make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.

... in this demonstration, with a make pulled and built today:

martind@sirius:~/tmp/D150109$ ~/download/make/make --version
GNU Make 4.3.90
Built for x86_64-pc-linux-gnu
Copyright (C) 1988-2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
martind@sirius:~/tmp/D150109$ cat Makefile
default:; $(MAKE) -f 2.make
martind@sirius:~/tmp/D150109$ cat 2.make
OUTPUT := $(shell env | grep MAKEFLAGS 1>&2; $(MAKE) -f 3.make)
default:; @true
martind@sirius:~/tmp/D150109$ cat 3.make
default:; @true
martind@sirius:~/tmp/D150109$ ~/download/make/make -j2
/home/martind/download/make/make -f 2.make
make[1]: Entering directory '/home/martind/tmp/D150109'
MAKEFLAGS= -j2 --jobserver-auth=3,4
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
make[1]: Leaving directory '/home/martind/tmp/D150109'
martind@sirius:~/tmp/D150109$

... is new with https://savannah.gnu.org/bugs/?58232 (FD_CLOEXEC not initialized on jobserver pipe for recursive make invocations) or so says my git bisect.  I wanted to use $(MAKE), so that the same Make program would be used for nested invocations, as https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html#MAKE-Variable recommends.  I can get rid of the problem by emptying MAKEFLAGS, as suggested by:

https://stackoverflow.com/questions/56485222/gnu-make-nested-calls

... eg like this:

martind@sirius:~/tmp/D150109$ cat 2.work-around
OUTPUT := $(shell env | grep MAKEFLAGS 1>&2; MAKEFLAGS= $(MAKE) -f 3.make)
default:; @true
martind@sirius:~/tmp/D150109$

... and maybe that's not unreasonable because maybe I wouldn't want to pass on eg -n to such (unusual) invocations.  That's what we've done in production to support the Make from Debian Bullseye, which cherry picked that as-yet unreleased fix.  Not passing the jobserver fds might be a more reasonable choice than scraping the arguments to $(shell), looking for $(MAKE), but, in that case, perhaps it would be better were Make not to pass MAKEFLAGS to $(shell) invocations either.  Deciding it's not a bug is fine by me - I really just wanted to make the issue and the work around better known.