I cannot reproduce the test_simplification failures locally -- can someone have a look?
test_markevery_linear_scales_zoomed fails locally even though there is no visible difference in the images acoording to the test triage tool; I guess this may be due to an extra tick on the edge, in which case I'll just generate a new reference image. Here too, another pair of eyes may be helpful.

They are mostly due to the tick on the edge, though curiously only for the svg tests:

• test_simplification.test_diamond:
  
• test_simplification.test_clipping:
  
• test_axes.markevery_linear_scales_zoomed
  

Looking at the markevery_linear_scales result, it seem like the svg->png conversion is a bit buggy. It appears as if the axes line is partially transparent (maybe 0.5 pixel wide, sort of thing?), so the ticks "bleed through". But if you look at the svg in eog, the axes is black, so there really shouldn't be a difference.

Can you generate the new baseline images (and perhaps open a new issue w.r.t. the conversion)? As mentioned above the tests pass fine locally for me, so I guess I can't generate them...

Tickers do not have to respect the view limit and are allowed to return ticks which are not visible.

Do you have a counter-example? Can we change the specification so that tickers do have to respect the view limits? (This issue is a perfect example why such a requirement would be helpful...)

I think that the idea here is that tickers are used in the classic autoscaling mode to determine the view limits. When called to actually get the ticks, however, I think they are called with the view limits after this autoscaling has already been done, and with the resulting view limits, so they should be able to return only the ticks that respect those limits. How all the tickers actually behave is another question.

Actually there seems to be another point where ticks are cropped to the actual limits: https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/axis.py#L1000
Not that smart_bounds seem to be mentioned anywhere in the docs... another good thing to get rid of?

Replaced by #7042.