There is indeed something fishy going on in the log scale autolimit logic. I have found a similar problem when using a ax.set_ylim(bottom=1e-4) call: the top limit is not recomputed automatically but remains at the level of the previous view. Since the new autolimit logic, this means it might be several orders of magnitde above if the initial range before the set_ylim was very large. MWE:

import matplotlib.pyplot as plt
import numpy as np
f,ax = plt.subplots(1)
x = np.logspace(-2,3,100)
y = x**1 * np.exp(-x/10)**2
ax.loglog(x, y)
ax.set_ylim(bottom=1e-3)
f.show()

On master:

On 1.4.3:

This resulted in a hour long phone discussion. It seems there are significant order of operations issues here.

OK, I got it: this is because the data limits of a collection include the physical extent of the artists that are part of the collection (in this case, the markers). I guess this is necessary because artists may be quite large...
Now, when the scatterplot is made, the y extent essentially comes from the marker size + margins. In fact, it can easily be checked that changing the size of the markers will change the ylims of the final plot. Ugh.
Note that AFAICT this is different from the issue pointed out by @zblz.

Yes, it looks like a different issue. @tacaswell: when you mention there is an order of operations issue did you mean with @anntzer's issue or the autolimit/zoom issue I mentioned? Maybe I should split it into a new issue...

@zblz: I am not sure that there is much to do about the issue you are raising. I guess the only alternative would be to store (upon a call to margins) somewhere the information that some limits should be automatically recomputed if the "opposing" limit is moved (until overriden by a call to set_{x,y}lims). I'm not too worried about the implementation (well, perhaps a bit) but more that this may lead to all kinds of strange behavior and confused users... or perhaps not?

@anntzer: In my opinion, the current behaviour is more confusing: if a limit is set automatically to 20% beyond the data range, I expect this to hold always, even when I change the range. So I would be in favor of storing which limits are automatic and which have been manually set, and compute the auto limits on every new view given the manually set ones.

Fair enough.

Coming back to my own issue: I thought that at least in theory, collections could return their limits as "data-value limit + axes-value limit" (the latter coming from the e.g. rightmost artist). However things are more complicated, because which artist has its rightmost point the furthest can depend on the xlims themselves (a larger artist more to the left can "catch up" a smaller artist more to the right if the scaling is compressed enough).

Current master yield this results with @anntzer's code:

while @zblz

I personnally find the new results to match my expections. @anntzer Can you confirm and close if that is the case?

I think this was closed by #7410

My example still suffers from the issue described in #7413.

Fixed by #13642, I believe.