This behavior is not related to bug #59395; that issue has to do with how target recipes are split into individual command lines.  This issue is discussing how an individual command line (or in this case the arguments to the shell function) are handled when they are sent to the shell (or not).

However, I am also not sure that the provided patch is correct.  This will always convert a newline to a space, regardless, which may not be correct in all situations (consider single-quoted strings for example).

I think there's a larger problem here.  Consider this makefile:

x := $(shell echo $(FOO))
all:;: x='$x'

The original request clearly expected that FOO would be treated the same way as a shell variable.  In the shell you'd get this:

$ FOO='
foo
bar
'

$ echo $FOO
foo bar

But, it's not a shell variable it's a make variable!  Make variables are expanded by make, before invoking the shell, and they don't follow the same escaping and quoting rules as the shell does.  So, if we have the above makefile and we run it like this:

$ make FOO='
foo
bar
'

then I'd expect that make would invoke the equivalent of this shell command:

/bin/sh -c 'echo
foo
bar
'

and that would yield errors because the commands "foo" and "bar" cannot be found.

Of course, if we had a makefile like this:

x := $(shell echo "$(FOO)")
all:;: x='$x'

(with quotes) then this would be the shell invocation:

/bin/sh -c 'echo "
foo
bar
"'

and the results (after newlines are converted on the output as discussed in the manual) would be " foo bar"

So, I'm a bit unsure how to proceed here.  Clearly the current behavior is not right, where adding a semicolon gives different output : the slow-path is causing issues.  But I'm not sure that fixing it to work completely correctly wouldn't be an issue with compatibility even though it's the right thing to do.

The problem is the overly complex way that make invokes subshells in the "slow path".  The slow path should be the SIMPLEST solution but instead it's more complicated and I'm not sure why.  It's not documented anywhere how shell will handle input strings that contain newlines; it only talks about output newlines, so I think that this behavior is more of an unanticipated result of how the parsing is done than anything intended.  Which doesn't mean that it won't be a backward-compatibility problem to change it.

I'll need to think about this a bit.

The patch in the attachment fixes the issue.