Another example where this PR is relevant is as follows:

import matplotlib.pyplot as plt
import numpy as np

fig, axes = plt.subplots(1, 3, figsize=(8,2))

im0 = axes[0].imshow(np.random.random((5,5)))
colorizer = im0.colorizer
axes[1].imshow(2 * np.random.random((5,5)), colorizer=colorizer)
axes[2].imshow(0.5 * np.random.random((5,5)), colorizer=colorizer)
fig.colorbar(colorizer, ax=axes)

Where a colorizer object is used to synchronize the cmap+norm of all subplots, and in that case it follows naturally that the colorizer object should also be the input for the colorbar.

(This is similar to https://matplotlib.org/stable/gallery/images_contours_and_fields/multi_image.html , which I will make PR for following this PR)

Just to be sure: Is this correct? - Previously colorbar must reference a ScalarMappable. If norm limits were not fixed, we use the ScalarMappable's data (if available) to autoscale, i.e. fix norm limits). The Colorizer now behaves like a scalar mappable without data.

I'm not yet 100% convinced, we need colorbars to accept colorizers right now.

• Advantage: You can create a bare colorbar without the need for a "dummy" mappable. - But how often do you need this?
• Disadvantage: The API and code becomes a little less clean because you allow different types.
• I'm torn on the shared colorizer example. It's fundamentally desirable that you can share a colorizer. - But I would say we are not really sharing, we are re-using. Technically, the example will have the same result if you use fig.colorbar(im0, ax=axes). This is because there's a skew in that autoscaling is done on the first array only (it's part of imshow(), which calls, im._scale_norm()). Passing the colorizer gives a false impression/desire that the colorbar does not specifically reflect the first data.
  I think accepting a colorbar primarily makes sense if we could get this to take into account all data:

  colorizer = mpl.colorizer.Colorizer()
  axes[0].imshow(np.random.random((5,5)), colorizer=colorizer)
  axes[1].imshow(2 * np.random.random((5,5)), colorizer=colorizer)
  axes[2].imshow(0.5 * np.random.random((5,5)), colorizer=colorizer)
  fig.colorbar(colorizer, ax=axes)
  

  But that's difficult. You cannot fix the scale in the fist imshow. But you also cannot defer to the colorbar() call because we don't have the data there. The only way I see would be a rearchitecting that norms could "collect" autoscaling i.e. unless fixed by some event, they would expand their range. Though I suspect that has its own set of problems.
  Unless we can get there, I'm not sure accepting a colorizer is a real advantage.

@timhoffm Thank you for considering this.

While I would of course have like to see this included, I cannot fault the logic leading you to the conclusion that this is not required.

In light of this, I have opened a new PR here, which simply updates the examples and documentation, but makes no changes to the API: #30112

Regarding auto-setting the norm, I am not convinced that it is worthwhile to seek a new solution here when multiple subplots are used, as I believe that best use is to set the limits manually, as is done in the example in the docs: https://matplotlib.org/stable/gallery/images_contours_and_fields/multi_image.html

norm = colors.Normalize(vmin=np.min(datasets), vmax=np.max(datasets))
...

And we are better served by steering users to that solution rather than complicating the default behavior.

My opinion on this matter is informed by the fact that I find the auto-scaler to be fine for prototyping, but whenever I need to make a publication-quality or complicated figure, I find that I have to manually set the limits anyways. (i.e. the autoscaler sets limits to 0.007373 to 0.99633 when 0 and 1 and much more reasonable limits.) The convenience of the auto-scaler is great for simple plots, but once I have multiple plots that need to share a colorbar, I would argue that it is no longer a simple plot and the user can be expected to know how to set the limits according to their needs.

I will close this seeing as #30112 was merged