Should the Custom Scale example also be updated at this point? Its __init__ method calls the parent __init__ method, which still requires axis. 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 the axis 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 the axis parameter and (ii) the registry can use classes with and without the axis 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 current ScaleBase.__init__ is empty, so it does not matter. But not calling super init would break subclasses if we decide later that we need ScaleBase.__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?