I think this is basically an instance of #13642 (comment), which I did not realize would affect many people, otherwise I'd have insisted more on it. (On the other hand, I did look a bit into it a while ago and IIRC fixing that was not so trivial :/)

The basic idea of #13642 was that previously, when autoscaling a Collection (e.g., a PatchCollection as producted by scatter()), we would attempt to take the marker extents into account (i.e., we'd have 5% margins starting from the edges of the markers rather than their centers). Clearly there are some issues to make that work -- the most obvious one being what happens if the marker size is bigger than the axes size(!); see the discussion in that issue for more examples. Also it seems weird that e.g. plot([0, 1]) would autoscale to (-0.05, 1.05) whereas the same call to scatter would use slightly larger margins.

So we decided that for collections whose size was in physical space (i.e. points), their extents would not be included in autoscaling (I still think that change is fundamentally for the better). Clearly, if a collection is in data space (i.e., x values), then they should still be taken into account, and they correctly are. What we did not handle was collections for which only x or only y was in data space -- as per my comment linked above, we handled them as fully in physical space. This is exactly the blended transform case you show here. Ideally, we'd want to handle the x and y axis separately (include them in autoscaling along the data-space direction, but not along the screen-space direction); if someone wants to look into this that would be great! However, in the mean time, I guess a partial solution would be to just handle them as if fully in physical space, which should approximately just be a matter of replacing transOffset.contains_branch(transData) by the correct call to contains_branch_separately.

Thanks a lot for the simple example. The fix in #17017 fixes this very naively. Not sure if its the "correct" fix.