I appreciate the cautious mindset, but I still think the analogy is
inapt. There is no new execution path here - only segregated
destinations rather than smooshed together stderr and even then only
when tracing is active.
ZSH_XTRACEFD was discussed from 2019-05-17 all the way to 2020-05-05.
This objection was not raised in spite of shell shock being much more
recent at the time and main Zsh contributors participating. I just
re-read that whole thread, which was dominated by debugging things.
Stephane Chazelas actually echoed my use-case point about why you
want to import the alternate destination (though as an fd there) and
Peter Stephenson suggested sticking with stdio was important which my
patch did. The already present `xtrerr` abstraction does almost all
the work. Indeed, the code to Zsh seems veritably "prepared for this
feature".
Zsh adapts its behavior to so much of its environment. Yes, this is
one more, but ZSH_XTRACEFD would also have been and seemed like on a
path to being a well received addition notwithstanding. I mean no
offense. I'm just honestly surprised this is the push back. There
may well be other issues with the patch.
Also, I should have said, the attached patch also fixes a memory
leak in xtrace mode { the zsfree(str2) bit }.