set -e in (subshells) does not work independently of outer context

[Jim Avera]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' 
-DSHELL -DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include 
-I../bash/lib   -g -O2 -Wall
uname output: Linux lxjima 3.0.0-15-generic #25-Ubuntu SMP Mon Jan 2 
17:44:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

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

Description:
set -e in (subshells) should be independent of surrounding context.
The man page says "[set -e] applies to the shell environment and
each subshell environment separately",
but actually set -e is prevented from working in a (subshell) if it is 
disabled in the
surrounding context.

Repeat-By:
    set +e
    (
      set -e
      cat /non/existent/path
      echo "Did not abort.  Isn't this a bug?"
    ) || true

Discussion:
    Set -e rightly ignores errors in the outer shell because of
    the || expression, but it is not clear why that should have any effect
    inside the (subshell) expression.

    For example, if you say
      set -e
      set -o errtrace
      trap 'echo -e "Command failed unexpectedly at \c"; caller 0; exit 
1' ERR

    then you might hope to find out the location of any unexpected command
    failures.  However, commands which fail in (subshell code) like above
    will not cause the trap because they will not abort the subshell.

    In summary, shouldn't set -e in (subshell code) operate independently
    of the surrounding context?