Why Colorbar? Isn't this rather a ColorMappable?

The objects uses a colorizer to map data to colors. It's just a corollary that objects that use colorisers can be associated to a colorbar.

jumping off this comment, I think this object is what would be hooked into for a colormap legend (for example for discrete colormaps) type situation?

Can you please clarify, what is a "colormap legend"?

Without understanding, I'd say no 😛. As said in the comment on the docstring, this object is basically "Data+Colorizer". And colorizer is per-se continous. One can make it look discrete through the (IMHO quite quirky) BoundaryNorm approach. But I wouldn't think about discrete colormaps right now - this abstraction doesn't change however good or bad they are currently supported.

what is a "colormap legend"?

A legend where the handler and label information is fed from a colormap. The most commonly requested use case is probably a scatter plot where folks wanna color the dots based on class. Also useful for heatmaps of classes (somewhat common in ml) and my motivating example was coded data on a heatmap.

I gave up on a categorical colormap a very long time ago b/c it kinda broke the cmap/norm abstractions (#6934), so one of my main reasons for being psyched about the colorizer pipeline is it doesn't have those divisions. A CategoricalColorizer that takes in a {category name : color} dict is almost definitely much cleaner to implement than my old hack of listed colormaps and boundary norm approach.

I think the subsequent note needs allow an update. My understanding is that this class is basically "Data+Colorizer" and related functionality like changed.

We need to be a bit careful with scoping. We've intentionally left out any Artist notion. So this is rather an abstract concept or concern or mixin or trait (or whatever you want to call it). That it needs association with an Axes is not a-priory clear.

axes is not used anywhere in the class itself. If we want to nevertheless add this here, we need a good reason for that.

This is a good point. Instead of having this here we can have a hasattr(mappable, 'axes') in colorbar().

We could make a very nuanced sematnic distinction here: If you keep the original name _ColorbarMappable, we could make the operational definition as "some object that can be passed to a colorbar". That would allow to add whatever is needed, including an optional axes.

OTOH I think I still like the conceptual definition "_ColorMappable = Data + Colorizer" more, even if this means colorbar() has to jump an extra hoop with hasattr(mappable, 'axes') (or possibly isinstance(mappable, Artist) - without having checked I assume that colorbar will do some thing additional for Artists in an Axes, that is not needed/possible for an abstract mapping). I propose to go this direction.

From a quick check, the only usage of axes in Colorbar seems to be

So the optional axes may already be cared for? Please re-check.

Side-note: I've found

Would it make sense to encode something like can_navigate() into _ColorMappable so that we move the responsibility for this logic from the colorbar to the mappable? - Possibly still needs a better name.