I don't think it's this easy. What happens if you pass different length extends to the second colorbar call? Cla is not adequate to change the colorbar.

It is a little strange to clear a colorbar axes, and/or reuse it. Why are you doing this? I'm 90% sure cb.ax.cla didn't do anything sensible before #20054 either.

Certainly as it stands, this PR is adding and inner_ax to a ColorbarAxes that already has an inner_ax and that is an unacceptable mess. It will work, but will lead to self.outer.inner existing, and if you start changing the extend lengths this will lead to very funny axes:

cb = fig_test.colorbar(pc, extend='both')    
# Clear and re-use the same colorbar axes    
cb.ax.cla()   
cb = fig_test.colorbar(pc, cax=cb.ax)

won't work.

I suppose that cb.ax.cla should just undo the nesting and return a non colorbar axes. If that is what we want, probably something like:

def cla(self):
   fig = self.outer_ax.figure
   pos = self.outer_ax.get_position()
   new = fig.add_axes(pos)
   ax_loc = self.outer_ax._axes_locator
   self.outer_ax.delete()
   self.innerer_ax.delete()
   self = new
   self._axes_locator = ax_loc

but I'm not 100% sure that garbage collects properly.

I agree, I'm not entirely sure how useful/practical this is. It came up when I was looking into the tests for axes_grid where the cax is being re-used, and I was trying to see if the same thing happens for regular axes with the state sharing. I couldn't even test that case because there isn't a remove method on the CbarAxes, so it throws an error currently.
(See ax.cax.cla() in this test here)

I guess changing the mappable associated with the colorbar is a reasonable use-case.

If we think the semantics of cla is "get back to the outer axes passed by the user stripped of any colorbar info", I think the above suggestion is the right track.

I think it is reasonable to expect that cax.cla() does the right thing at at least visually restores the Axes to the "blank" state.

This is pushing towards type promotion being the better option here as it lets us "demote" the Axes back to a normal axes in cla.

colorbar probably also needs to pick up some logic to say "if the cax I've been given has already been promoted at least once, re-use the inner/outer logic rather than re-adding it". I now suspect (but have not chased through to be sure) that this is the core issue in #19553 's failing tests.

I guess the question is if #19553 was failing before #20054 was rebased into it. However, that test passed #20054, so I'm not clear why this PR causes problems.

This is pushing towards type promotion being the better option here as it lets us "demote" the Axes back to a normal axes in cla.

I agree that demoting is the right thing. I'm not quite sure what you mean by "type promotion", and I don't see anything in the conversations of #20054. If you mean casting the original axes to ColorbarAxes that is basically what we are doing, so I'm not clear how it simplifies things. Certainly we would have to do some sort of dance like above...

 def cla(self):
        """
        Reset the colorbar axes to be empty.
        """
        # need to low-level manipulate the stacks because we 
        # are just swapping places here.  We don't need to 
        # set transforms etc...
        self.figure._axstack.add(self)
        self.figure._axstack.remove(self.outer_ax)
        self.figure._localaxes.add(self)
        self.figure._localaxes.remove(self.outer_ax)
        
        self.__dict__.update(self.outer_ax.__dict__)
        self.inner_ax.remove()
        del self.inner_ax
        del self.outer_ax
        
        self.xaxis.set_visible(True)
        self.yaxis.set_visible(True)
        for spine in self.spines.values():
            spine.set_visible(True)

        self.set_facecolor('white')

seems to work fine, except the callback for the mappable gets called while the axes is in the indeterminate state for some reason, so we need a try/except on draw_all (did I mention I don't like callbacks?)

Setting all the axis visibility/facecolor is a bit hokey, as we should probably set the state to what it was before colorbar was called? But I'm not sure anyone is going to be using the axes for anything but a new colorbar, so maybe that is OK?

Closing in favor of #20330