As you say, done simply this would be a major backward-incompatibility
and very complicated to explain as well. To avoid the backward
-incompatibility we'd need to do some kind of semi-evaluation that only
processed functions we know (a) might have side-effects, and (b) will
expand to the empty string.
What about adding something similar to .ONESHELL that optionally enables
this functionality?
Also complicating things could be the printing of the command line to
be invoked (which can only happen after expansion), combined with
output sync: maybe this would just work, not sure. It would need to be
checked. Definitely output sync would be even more critical than
previously because at least today (for non-recursive builds) you know
that all the command lines are printed serially, even if command output
appears in parallel.
It just occurred to me we wouldn't even be able to make use of the feature
I stated because I switched to .ONESHELL last week.
Another concern is that running significant code in the forked process
before the exec would mean we'd have to give up the performance gains
achieved by switching back to vfork(), and switch permanently to
fork(). See the discussion in https://savannah.gnu.org/bugs/?44555
hm ... that's a nice optimization, and I don't see an obvious way around it for what I'm suggesting.
-brian