Great, that looks a lot better.  Thanks!

A couple comments though:

+   .. note:: If you attach a handler to several loggers, it may emit the same
+      record multiple times. In general, you should not need to attach a
+      handler to more than one logger - if you just attach it to the
+      appropriate logger which is highest in the logger hierarchy, then it
+      will see all events logged by all descendant loggers, provided that
+      their propagate setting is left set to ``True``. A common scenario is to
+      attach handlers only to the root logger, and let propagation take care of
+      the rest.

Would it be better to say something like, "If you attach a handler to a logger and one of its ancestors [and similar changes later]..."  The reason I ask is that it seems like there is a valid use case for attaching a handler to more than one logger (which I have used), which is if the loggers aren't in the same ancestry chain.  For example, if I want loggers "app1" and "app2" to log and nothing else, I could attach a StreamHandler to those two loggers and a NullHandler to the root logger.  It seems like the above would discourage that pattern.  Or is that not recommended?  (I suppose you could also do this using a custom filter by name on the root logger, though I don't know which technique is preferred.)

> it never makes sense to add more than one filter

Here I was referring to the restricted case of using default filters by name.  For example, it seems like it would never make sense to filter by "A.B" and "A.C" because that is just an obfuscated way of filtering by the simpler and equivalent "A."  Does that make sense?  (I'm not suggesting any changes to the docs in this comment.)