The use of the term "filter" is pretty confusing.  I would normally say
it was just me, but a bunch of other Twisted hackers seemed to interpret
it the same way: a "filter" is something that has an opportunity to
remove something else.  For example, the python builtin function
"filter".  Experimentation with the filters list seems to confirm this
impression, since later filters do not have an opportunity to access the
warnings that earlier filters have removed.  The intuitive leap there is
to assume that inserting a filter at the head of the list won't do
anything different than inserting it at the tail, since a later filter
will remove it.

I can't think of an obvious recommendation to improve the text for the
filter system itself, because upon reading it in more depth, it's fairly
clear.  Maybe the heading could be changed to something more like
"intercepting warnings" or "controlling the way that warnings are
emitted"?  Something attention-grabbing that describes its purpose and
doesn't use the word "filter".  Even a sub-heading which simply
described how to use 'always'   filter to cause every warning to be
emitted would be helpful.

The biggest improvement to the documentation for "catch_warnings" would
be to put it in a section of its own, "How To Test Your Code Which Uses
Warnings", not as a footnote in "Available Classes".

(Also, as a minor note to be taken at your discretion: should
catch_warnings be named PEP 8 style as a class, since it is one?  I
don't really want to open that can of worms after reading the
interminable threading.Event thread, but it seemed worth saying as long
as was talking about this...)