Re-trigger of errors by quit after zgoto

Question about etraps:

r1()
    w "r1 start",!
    d r2()
    w "r1 end",!
    q

r2()
    w "r2 start",!
    n $etrap
    s $etrap="w ""etrap"",! zgoto "_$zlevel
    d r3()
    w "ecode: ",$ecode,!
    w "r2 end",!
    q

r3()
    w "r3 start",!
    s $ecode=",UTEST,"
    w "r3 end",!

When r1 is run it gives the following output:

> d r1^test()
r1 start
r2 start
r3 start
etrap
ecode: ,UTEST,
r2 end
r1 end

This shows that r1 completes normally, without re-triggering the error from r3.

I expected the error to be re-triggered by quit at the last line of r2, and the code to terminate with an error without printing r1 end, as described in the documentation:

If a QUIT command is executed that returns control to a less nested level than the one where the error occurred, and the value of $ECODE is still non-empty, [...] the current value of $ETRAP is executed.

Why doesn't quit in r2 re-trigger the error?

Does zgoto make it so that quit does not re-trigger the current error? Its documentation doesn't seem to indicate that.

M language expert Shabiel answers this in the YottaDB Discord channel:

I agree with you: zgoto does something weird. [...] zgoto still continued as if no error in the error frames happened. [...] Zgoto is not M standard, so YottaDB can make it do whatever YottaDB wants.

If I used $Etrap, I would always use $Estack to do the pops correctly. I would not combine the M standard $ETRAP with $ZLEVEL, as they are not exactly "compatible" language wise. One uses $STACK or $ESTACK, another uses $ZLEVEL, which counts differently I think.