It seems odd that this special casing has to be done, what's stopping the more generic code path on L1228 being hit below? (perhaps LogNorm doesn't have a _scale attribute set?)

The contours have boundaries so we get caught in the first case which just uses a linear scale.

Should that first case be modified to get the scale from self.norm._scale (if present) instead then?

Yes, thanks, I think you are right. Lets see if this passes the other tests...

Yes, this works, and I think is more consistent with what users would want for other boundary norm cases. Thanks!

This now seems like you are special-casing LogNorms only for contoursets.

I think the main issue is that there are some self.boundaries, but the norm is changed so we don't want to take that path, so perhaps we could add a check on the norm below.

(self.boundaries is not None  and type(self.norm) is colors.Normalize)

What I'm worried about is that we are whacking the LogLocator() with this change, but we also want to be able to handle any other special-cased locators too without adding additional if clauses above.

It may be valid, but I'm not following your concern here. This is usually only called at init, or if the norm is changed, both of which are pretty destructive to the colorbar. Everything gets whacked, as noted in the docstring.

My concern is mostly that this handles: locator=ticker.LogLocator(), and will this mean that we'll also need to special case SymmetricalLogLocator() in the future.

But, looking at the contour code it looks like only log-scales are special cased, and they set an explicit logscaled attribute. So, should we actually be using that here instead?

if getattr(self.mappable, "logscale", False):