"As for (b), do you not think a large number of users will not bother
with the hierarchical aspect of the logging framework? I'd say you need
to be pretty advanced/large scale before that becomes interesting."

I disagree with this. The hierarchical set up is one of the key points
of the approach. Casual users may not use it, but there are a lot of
users who do - and not only on advanced or large-scale systems. Users wh
o don't need hierarchies don't have to use them, but the system has to
support those who find them useful. 

"I don't really understand why accepting such a patch would be a
problem, as it's a simple change that wouldn't break backwards
compatibility. It's surely got to be better than exiting with a python
stack, which is what happens today."

Any software might result in an exception if you don't interface to it
in the expected and documented way. And, in my previous comment, I
merely set some conditions which a patch would have to meet. Also, as it
is definitely the case that many users use the hierarchical feature,
even if you don't, I expect that the qualname setting will stay.

"(To give an idea of the bloat-factor, since migrating to the logging
framework a typical configuration file for my system is now roughly 3
times the size it used to be for the same functionality)"

How big is that in KB? Disk space is pretty cheap these days. If it is a
big problem for you, you can always try using your existing
configuration format, reading it yourself and using the programmatic API
to configure logging yourself. It should be a small bit of up-front work
which can then be used on all your future projects.