This broke in #13741 (sorry for approving that one)

Given the scale and connectivity of Matplotlib missing higher-order consequences of changes is inevitable. We should do our best to not make mistakes, but it is also expected that we will all miss something from time to time.

Is there a simple fix for this? I'm 50/50 in putting this in 3.2.x bug fix vs 3.3 (been broken for a while, but also definitely looks like a bug that no one would be relying on unless someone discovered that setting a negative pad "suctions" the title to the top of the axes).

I don't see any simple fix for now. Essentially this shows that coupling the two otherwise distinct properties may not have been the best idea.
Feel free to remilestone.

Well update_title_pos tries to position the text above the xticks and xlabels. I guess we could just not call the update if there is a pad or just set the position assuming pad==0 and then pad.

FWIW I would imagine you get similar bugs with pad for xlabel and ylabel which update_title_pos was based on.

Note I’m pretty sure the user can still specify y for the title and have it be where they want it to be.

I guess my preference would be to not auto position if the user has set pad.

Yes, but there is always a pad set through rcParams["axes.titlepad"] = 6.0. And I don't currently have any good idea about how to distinguish the cases, i.e. how would we ever know what the user actually wanted?

Perhaps you've looked at it more carefully than me, but its set to None in the signature. It seems that we just track if its None?

FWIW, we also have the same problem for y=1.0 with title. The workaround for now is:

import matplotlib.pyplot as plt

fig, (ax1, ax2) = plt.subplots(ncols=2)
for ax in (ax1, ax2):
    ax.set_title(f"Title 1", pad=-20, y=1.000001)
ax1.tick_params(labelbottom=False)
plt.show()

which turns off the auto positioning. We just need to extend that logic to pad....

One liner if we can assume pad=-20 is meant to be manually placed (i.e. the -20 is relative to y=1)