Yeah, hope is a good thing.  But I've spent the last 20 years debugging an X11 application based on a Lisp interpreter, I save hope for fireflies, my dog, and my daughter these days. :-)

To the OP:

I don't follow Gentoo closely, but I have acquaintances who do.  Between them and the occasional foray into the forums, I've gotten the impression that providing CFLAGS for optimization is associated with having hard-to-debug problems.  They increase performance noticably only in a few applications.  Python being a  dynamic language, function calls and even variable references can be quite inefficient anyway.  So I see no good reason to compile Python with aggressive CFLAGS, because it should be used only for moderately performance sensitive applications and as "glue code" and to provide UI.  Instead, use them only for the specific applications that benefit (I suppose matplotlib *might* be one).

Second, I tend to agree with the maintainers.  The packages.env / pydebug.conf approach is the right thing for this kind of variant build.

Third, you said you hoped to get better backtraces from --with-pydebug.  That's a vain hope.  Such options are intended to get better backtraces of C code from coredumps where the interpreter breaks down, not of Python code induced by Python exceptions caused by problems in user code.  If you have trouble interpreting a backtrace, ask on python-list@python.org or comp.lang.python (they mirror each other, you only need one).  If, after understanding the backtrace, you have an idea for way to get a better backtrace in this case, you can suggest it on python-ideas@python.org.

Unfortunately, reporting "this backtrace is unintelligible, please improve it" as an RFE on the tracker is likely to get the reply "You're right, but we don't know how at this time.  Patches welcome!"  But you could try that if all else fails.