Near as I can tell, from 2.3, io_here has precedence over string concatenation of normal tokenization so the output of bash should be:
A:echo line 1
Syntax error: Missing right paren
Syntax error: Missing closing double quote

as the list production terminates at the first newline, and a new one doesn't start until after the second line with XXX to satisfy the second io_here. It can be argued provisions for trying to find the end of an open string should continue after the io_here body, but Item 7 of 2.3 has the newline terminating it.

The first newline is the one left after line joining has been done. Before tokenization starts the input file position should be pointing to the character after it so the first io_here can immediately start reading the body from there until the first XXX line, and that advances it so the second might be processed, and the line after starts a new list, not continues as if no io_here was present. The syntax error detection happens before the second block gets consumed, but the presence of the operator while scanning for the right paren reserves it.



On Wednesday, February 24, 2016 Joerg Schilling <Joerg.Schilling-8LS2qeF34IoQrrorzV6ljw@public.gmane.orgnhofer.de> wrote:
Eric Blake <eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> > --- code
> > prefix() { sed -e "s/^/$1:/"; }
> > DASH_CODE() { :; }
> > 
> > prefix A <<XXX && echo "$(prefix B <<XXX
> > echo line 1
> > XXX
> > echo line 2)" && prefix DASH_CODE <<DASH_CODE
> > echo line 3
> > XXX
> > echo line 4)"
> > echo line 5
> > DASH_CODE
> > 
> > --- bash 4.3.42 output:
> > A:echo line 3
> > B:echo line 1
> > line 2
> > DASH_CODE:echo line 4)"
> > DASH_CODE:echo line 5
>
> So, it looks like bash is interpreting this as "first newline that is
> not in the middle of another shell word), and parses the entire $(...)

I would like to get an explanation on what I should understand by:

	"first newline that is not in the middle of another shell word)


BTW: If I replace $(..) by `..` and feed the code to the original SVr4 Bourne 
Shell, I get the same output as you got from bash. I would guess that the bash 
output you added above is correct.

Note that the command substitution is part of a " quoted string and even 
without that, it would need to be parsed first.

The POSIX version from ksh88 (seen on Solaris) behaves the same with $(..) and 
the `..` variant and the same as bash.

The fact that ksh93 behaves different with $(..) and the `..` variant makes it 
obvious that ksh93 has a bug.

Jörg

-- 
EMail:joerg-lSlhzV3CM+2sTnJN9+BGXg@public.gmane.org (home) Jörg Schilling D-13353 Berlin
joerg.schilling-8LS2qeF34IpklNlQbfROjRvVK+yQ3ZXh@public.gmane.org (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'