This works for me, though it appears tests are not happy about it. Never mind, seems you've pushed a fix.

Untested, but I think something along the lines of the following may work too, be simpler, and cover more cases?

diff --git i/lib/matplotlib/collections.py w/lib/matplotlib/collections.py
index 181e46b45..55a681000 100644
--- i/lib/matplotlib/collections.py
+++ w/lib/matplotlib/collections.py
@@ -211,8 +211,6 @@ class Collection(artist.Artist, cm.ScalarMappable):
             # we may have transform.contains_branch(transData) but not
             # transforms.get_affine().contains_branch(transData).  But later,
             # be careful to only apply the affine part that remains.
-        if not transOffset.is_affine:
-            offsets = transOffset.transform_non_affine(offsets)
 
         if isinstance(offsets, np.ma.MaskedArray):
             offsets = offsets.filled(np.nan)
@@ -226,7 +224,8 @@ class Collection(artist.Artist, cm.ScalarMappable):
                 # also use this algorithm (like streamplot).
                 result = mpath.get_path_collection_extents(
                     transform.get_affine(), paths, self.get_transforms(),
-                    offsets, transOffset.get_affine().frozen())
+                    transOffset.transform_non_affine(offsets),
+                    transOffset.get_affine().frozen())
                 return result.transformed(transData.inverted())
             if not self._offsetsNone:
                 # this is for collections that have their paths (shapes)
@@ -234,14 +233,13 @@ class Collection(artist.Artist, cm.ScalarMappable):
                 # (i.e. like scatter). We can't uniquely set limits based on
                 # those shapes, so we just set the limits based on their
                 # location.
-                # Finish the transform:
-                offsets = (transOffset.get_affine() +
-                           transData.inverted()).transform(offsets)
+                offsets = (transOffset - transData).transform(offsets)
                 offsets = np.ma.masked_invalid(offsets)
                 if not offsets.mask.all():
                     points = np.row_stack((offsets.min(axis=0),
                                            offsets.max(axis=0)))
                     return transforms.Bbox(points)
+
         return transforms.Bbox.null()
 
     def get_window_extent(self, renderer):

The point is that transOffset - transData will check whether transOffset and transData contain the same subtransform and if so will cancel them out exactly (that's how Transform.__sub__ is implemented). So this would work even if e.g. transOffset = someothertransform + transData or whatnot.

I really don't understand why transforms were implemented with add and minus to really mean multiplication and multiplication by the inverse. Worse, these operators are, as far as I can tell, completely undocumented. So I'm not in favour of adding them to the code until this situation improves.

I really don't understand why transforms were implemented with add and minus to really mean multiplication and multiplication by the inverse. Worse, these operators are, as far as I can tell, completely undocumented. So I'm not in favour of adding them to the code until this situation improves.

Woah, that is confusing! I was looking at your changelog and got really confused with what was happening because it never crossed my mind that + could ever mean multiplying two transformations together.

I should stipulate that __sub__ and __add__ are documented, but as far as I can tell they don't come up in the webpage docs.

There was one transform operator in the code before (an addition: transOffset.get_affine() + transData.inverted()); there's still one in my proposed patch (transOffset - transData), so in that sense it doesn't make things worse. And my proposed patch avoids splitting the affine and non-affine parts of transOffset unless we really need to do it.

As to why multiplication and division are implemented as addition and subtraction: I didn't make that choice so I can't tell, but it's not a completely silly choice either. In particular, if you follow the matrix multiplication semantics, you'd have A + B [current] === B * A [matrix], i.e. apply B then A. But then you simply don't have a good way to write A - B (apply A then the inverse of B) because there's no leftdivide in python. Sure you could write (1/B) * A but then it becomes much more awkward to get the "enforced cancelling" when A = B (unless 1/B returns a special object which knows its inverse), and even then (1/B) * A (or B**-1 * A) doesn't read that nicely either.

There was one transform operator in the code before

Ha ha, guess why?

I've implement it with the minus sign and put a comment. The extra code in transform to handle the inverse properly does seem quite helpful.

... added a simple test as well..

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout v3.2.x
$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 f091a4d92e0a73e702e15c172c884d35c9a478a2

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #17206: FIX: bypass inverse in collection'

4. Push to a named branch :

git push YOURFORK v3.2.x:auto-backport-of-pr-17206-on-v3.2.x

5. Create a PR against branch v3.2.x, I would have named this PR:

"Backport PR #17206 on branch v3.2.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.

OK, I have real troubles manually backporting:

$ git checkout v3.2.x
error: pathspec 'v3.2.x' did not match any file(s) known to git

Like maybe this PR isn't worth back porting, but the instructions used to work

OK, I have real troubles manually backporting:

$ git checkout v3.2.x
error: pathspec 'v3.2.x' did not match any file(s) known to git

Like maybe this PR isn't worth back porting, but the instructions used to work

Works fine for me on a fresh git clone, maybe you need to fetch the remote branch to your repo?