At the moment the NavigationToolbars 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)

In backend_wxagg.py the NavigationToolbar2WxAgg 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 to Toolbar and this breaks e.g. embedding_in_wx3_sgskip.py

Toolbar = NavigationToolbar2WxAgg

In backend_wxcairo.py the NavigationToolbar2Wx is imported.
The assignment for Toolbar is missing. get_canvas is broken and would be fixed by the PR.

So the options are:

• have a single NavigationToolbar2Wx in backend_wx with get_canvas as return type(self.canvas)(self, -1, fig); import it to the other backends and assign it to Toolbar
• have derived classes in backend_wxagg and backend_wxcairo; both assigned to Toolbar 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 single NavigationToolbar2Wx, I'm fine with this as well.

What is the situation about deprecating the NavigationToolbars? 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 the get_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.

The SubplotToolWX 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...