Command substitution and exiting from deeply nested subshells

[Carlos Pita]

Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib
-D_FORTIFY_SOURCE=2 -march=i686 -mtune=generic -O2 -pipe
-fstack-protector --param=ssp-buffer-size=4
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
uname output: Linux netbook 3.11.1-1-ARCH #1 SMP PREEMPT Sat Sep 14
20:31:35 CEST 2013 i686 GNU/Linux
Machine Type: i686-pc-linux-gnu

Bash Version: 4.2
Patch Level: 45
Release Status: release

Description:
  I'm not completely sure whether this is a bug or not but it seems
not possible to immediately exit a shell when an error happens at 2+
levels of subshell nesting.  Specifically, there is a command at the
top-level shell waiting for the results of a command substitution.
This second command in the first subshell is in turn waiting for the
results of another command substitution. This innermost command fails
but the awaiting commands still finish their execution as if the error
never happened. I've tested this with set -e, set -E, an ERR trap,
explicit exits at each subshell, but to no avail. Below is an example
to reproduce it.

Repeat-By:

trap 'exit 1' ERR

set -e -E

function xxx {
  echo xxx1
  exit 1
  echo xxx2
}

function yyy {
  echo $(xxx) yyy
}

yyy

# => xxx1 yyy
# I wouldn't expect the echo to print any output or execute at all.