The resolution for me (the python-pptx and python-docx libraries) is clear, to add a
separate `import collections.abc` statement rather than assuming (hoping) that the
`collections.abc` module is available on an `abc` attribute of the `collections` module.
I chalk that up to a gap in my knowledge of the guarantees provided by module imports
and falling into trusting my method just because it worked :)

But I will argue for maintenance of backward compatibility here, just for the sake of
those unable or unwilling to modify existing code.

1. Removing the availability of e.g. `Container` directly from `collections` is not the
   same as removing the availability of `abc` from collections. The deprecation warning
   we have all seen many times admits both interpretations. So I would argue we have at
   least not _explicitly_ stated that `import collections; collections.abc` would stop
   working.

2. `import collections; collections.abc` worked in Windows Python 3.9.6. As such, it was
   part of the de-facto spec. When we publish a behavior, a certain number of folks will
   come to depend on it, whether it is stated or not. So there will be breakage here.

   It's not my place to judge whether the breakage or restoration of the behavior is the
   greater value; my claim is only that there will be breakage cost. That would include
   the time to deal with additional issue reports from folks who don't find this issue
   before reporting.

So I've said my piece on this. I'm grateful for your attention to this conversation and
will cheerfully accept whatever resolution you decide on. Thanks to all of you for
participating in this great project that empowers so many; I'm very proud to be a small
part of it :)