Thanks for providing an easy to copy/paste example. I can confirm this is a problem on the master branch, with python 3.6. Adding plt.show to the end of that and then moving the axis slightly makes the limits correct, but as you say they should be correct even before the figure is drawn.

@dstansby Can you render a figure with miss-matched limits?

The figure shown by calling plt.show() at the end of the above code block has mis-matched limits.

If somebody picks this up, this would be a good test (adapted from #10691):

def test_shared_axes_retick():
    fig, axs = plt.subplots(2, 2, sharex='all', sharey='all')

    for ax in axs.flat:
        ax.plot([0, 2], 'o-')

    axs[0, 0].set_xticks([-0.5, 0, 1, 1.5])  # should affect all axes xlims
    for ax in axs.flat:
        assert ax.get_xlim() == axs[0, 0].get_xlim()

    axs[0, 0].set_yticks([-0.5, 0, 2, 2.5])  # should affect all axes ylims
    for ax in axs.flat:
        assert ax.get_ylim() == axs[0, 0].get_ylim()

As per my comment in #18529, this is fine, and I can see why we'd expect the axes to match. However, fi we change this, the converse - where the user cannot explicitly set one set of ticks, but not the others, becomes impossible. I think its pretty easy for a user to loop through the axes and explicitly set them, rather than us doing it automatically, and making it impossible for them to be different.

Over all, does "sharing" an axes mean that everything is the same about the axes? I think the major convenience is having zooming linked when looking at the plot interactively, so that when I zoom on one axes, it zooms on the other. I'm less interested in the decorations on the axes precisely tracking one another, particularly if the user specifies them manually.

@jklymak the issue is labeled 'confirmed bug' and has assigned milestone. What's the preferred way of initiating work on an issue like this?

@l-johnston Not your fault at all - after some thought, I'm just not sure I agree that this is really something we want to do. I actually have it on today's dev call to quickly decide...

OK, dev call today it was decided that this is the intended behaviour. The fix is believed to be easier than #18529...