ATTENTION: This patch depends on the following patches described here
<https://inbox.vuxu.org/zsh-workers/CAGdYchufLwUgpKVU6b5eOiF15p0njFr59H1q9XizypwNjzqKzw@mail.gmail.com/>
:
- patch-01-revert-mistaken-errexit-patches.txt
- patch-03-fix-negation-statement.txt
- patch-04-fix-function-call.txt

After quite some thinking and code studying, I realized that what is really
missing/wrong is a lack of this_noerrexit resetting in the execlist
function. Adding that fixes the problems for the eval and source
statements. It also makes my previous fix for function calls, in patch
patch-04-fix-function-call.txt, redundant. Therefore, the patch below
reverts that fix. Since that other patch isn't submitted yet, it could be
combined with the one below into a single patch. If you prefer that, let me
know and I will prepare a combined patch.

The patch also significantly expands the description of the variables
noerrexit and this_noerrexit. Since I spent so much time understanding the
role and correct usage of these variables, I figured that writing down my
findings might prove useful to future developers.

For the record, here are examples of eval and source statements that don't
behave correctly in the current Zsh:

set -e
> eval "{ false && true; }"
> echo done


The eval statement should trigger an exit but the current Zsh keeps going.

set -e
> source <(echo '{ false && true; }')
> echo done


The source statement should trigger an exit but the current Zsh keeps going.

While working on the patch I discovered yet another case where the current
Zsh misbehaves:

set -e
> { false && true; } || false;
> echo done


The second "false" should trigger and exit but the current Zsh keeps going.

I was expecting that the current Zsh would also misbehave for the following
case. Interestingly, it doesn't.

set -e
> x=$({ false && true; })
> echo done


The assignment correctly triggers an exit. Why is this working while the
similar examples with eval and source statements don't? The reason is that
in this case the "{ false && true; }" is evaluated in a sub-shell.
Technically, the evaluation in the sub-shell ends with an incorrect value
of this_noerrexit. However, that doesn't impact the evaluation of the
assignment, which happens in the parent shell, where this_noerrexit remains
unchanged.

Philippe