Should theCustom Scale example also be updated at this point? Its__init__ method calls the parent__init__ method, which still requiresaxis. However, I think it could just not call the parent method (several of the built in scales do not).

I think the note here also needs updating

@rcomer This commit/PR is one step in removing the parameter (see#29349). The points you bring up have to be addressed in the course of making the parameter fully optional. I believe it's best to address them after making theaxis parameter in__init__ optional (step 3#29349). I will do that, but I'm undecided whether it's better as part of this PR or easier to review separately. Technically, the aspects (i) it's possible to use/create scale classes without theaxis parameter and (ii) the registry can use classes with and without theaxis parameter are independent - which could suggest making separate PRs for easier review. OTOH practical use is only possible after both have been implemented, which could suggest putting both in to one PR.

Specific note on:

However, I think it could just not call the parent method (several of the built in scales do not).

I'd rather not go this way. The currentScaleBase.__init__ is empty, so it does not matter. But not calling super init would break subclasses if we decide later that we needScaleBase.__init__. Not calling is okish for our own classes, which we have control over and can update if needed. But I would not recommend that for third-party subclasses. Since we can easily prevent that hassle through#29349 step 3, I would take that route.

Could this PR wait till after step 3?

Looks good to me overall - I left a couple of suggestions to tighten language in the release note, and a question about the possiblity of other parameter names than "axis" inline.