At the moment theNavigationToolbars for wx are broken and inconsistent and this PR would not fully fix things.

As you wrote, in 'master'backend_wx.NavigationToolbar2Wx uses this:

    def get_canvas(self, frame, fig):        return FigureCanvasWx(frame, -1, fig)

Inbackend_wxagg.py theNavigationToolbar2WxAgg is derived and marked deprecated:

@cbook.deprecated("2.2")class NavigationToolbar2WxAgg(NavigationToolbar2Wx):    def get_canvas(self, frame, fig):        return FigureCanvasWxAgg(frame, -1, fig)

What is missing here is an assignment toToolbar and this breaks e.g.embedding_in_wx3_sgskip.py

Toolbar = NavigationToolbar2WxAgg

Inbackend_wxcairo.py theNavigationToolbar2Wx is imported.
The assignment forToolbar is missing.get_canvas is broken and would be fixed by the PR.

So the options are:

• have a singleNavigationToolbar2Wx inbackend_wx withget_canvas asreturn type(self.canvas)(self, -1, fig); import it to the other backends and assign it toToolbar
• have derived classes inbackend_wxagg andbackend_wxcairo; both assigned toToolbar as well

I don't have a strong preference for either of the options, but a small preference for the derived classes as I prefer explicit over implicit. If you prefer the singleNavigationToolbar2Wx, I'm fine with this as well.

What is the situation about deprecating theNavigationToolbars? If they are deprecated, it should be consistent.
The derived classes have the advantage that the deprecation messages are a bit clearer.

Removal of the Toolbar alias came in in#9938 and I would support either keeping it out (and fixing the example), or, if we want to have it back, it should be present for all backends (as a "standard backend interface").

I would prefer keeping a single class to make it easier to write renderer-independent code. (And yes, having a single alias for Toolbar would also help that purpose, but again in that case it seems preferable to let all relevant backends have it.)

For 3.0 the Toolbar alias certainly should be removed.
For 2.2 the examples should be updated not to use it, as the 'reference' example does not have it:https://matplotlib.org/users/navigation_toolbar.html
For the alias in 2.2 I'm not sure. I would count the removal as API change.

I've seen that theget_canvas method is just used for the subplot configuration, so I'm fine with the single class. I don't like the subplot configuration as it is as it does not match the GUI look and feel.
For the tool manager version that is to be done, I would prefer a real wx implementation, i.e. with wx sliders.

TheSubplotToolWX class seems to be unused. Right?

I agree strongly with you that native widgets should be preferred (see e.g.#8683), but see also#7696 for arguments against it.

Can you fix the examples in a separate PR (or list the examples that need to be fixed)?

SubplotToolWx seems to essentially be a copy of the body of configure_subplots. I'm fine with deprecating it or making it private (in general I think all these are backend implementation details...).

I've just submitted PR 10518 to fix the inconsistencies. With this, 10518 and 10429 we're probably done for 2.2.
Thanks a lot.

Regarding native vs. Matplotlib widgets: I think for Subplot it would make sense to implement it in Matplotlib, but not as separate window. The best would be to have the plot borders draggable...