The Travis failure seems to be unrelated.

Well, it looks like the changes to the OSS version of travis have finally caught up with us safe to ignore that.

Reading more carefully the failure was unrelated to our builds getting suspended, it was trying to get an image from the network. I still agree we can disregard that for reviewing this PR.

#12513 for other discussion.

Consusensus on the call was that we can not break

plt.subplot(222)
plt.subplot(222)

because as much as we think this is a bad idea (and holding onto the returned Axes object leads to significantly better code) there is no other way to "get back to" a previous axes using just the pyplot API. The logic for this re-use should fully live in pyplot.subplot and only check the subplot spec and warn if any kwargs are passed. The information we need to sort out if the given Axes exists in the Figure already exists on the Axes objects so we don't need to add any new state (just walk state we already have).

EDIT: sorry cross post with above....

I've not looked at all the changes here carefully, but can try to do so. However, as discussed on the weekly call, we need to make sure

ax0 = plt.subplot(2, 1, 1)
plt.subplot(2, 1, 2)
ax1 = subplot(2, 1, 1)
assert ax0 == ax1

still works, preferably without warning....

We did discuss the extra arguments case and decided that

ax0 = plt.subplot(2, 1, 1, polar=True)
plt.subplot(2, 1, 2)
ax1 = subplot(2, 1, 1, polar=False)   #  Warns about ignored kwargs
assert ax0 == ax1    # pass
ax2 = subplot(2, 1, 1, polar=True)   #  Warns about ignored kwargs
assert ax0 == ax2    # pass

should both warn that the second and third call has kwargs that are being ignored, rather than trying to check if the kwargs match the creation kwargs they should just be ignored. This precludes users from getting two axes over one another using pure pyplot, but they can still do this via non-pyplot:

ax0 = fig.add_subplot(2, 1, 1, polar=True)
ax1 = fig.add_subplot(2, 1, 1, polar=False)   # creates a *second* cartesian axes

Note that in that case, plt.subplot(2, 1, 1) will be somewhat ill-defined, in that it will return the first axes added.

Ping @tacaswell, @anntzer, @timhoffm in case I got any of that incorrect.

@tacaswell, @jklymak, I've attempted to implement that behavior, but I am getting some unit test failures related to twin axes, and I'm a bit stuck. Would you take a look, please?

I now understand the problem with twin axes. The method matplotlib.axes._subplots.SubplotBase._make_twin_axes calls matplotlib.figure.Figure.add_subplot, which in my implementation is still doing the key lookup.

To avoid this issue, is it OK if the logic for reusing an existing subplot lives only in matplotlib.pyplot.subplot, and not in its object-oriented sibling matplotlib.figure.Figure.add_subplot?

I think this PR was replaced by #19153.