I guess we need to standardize on a name there, effectively saying "a module with a Foo global is a backend". I'm fine with calling that Backend, I just want to make sure we agree on the name.

OTOH, another approach (#18854) would be to move "everything" to the FigureCanvas class ("a module with a FigureCanvas global is a backend"). (Note, in particular, that this allows reusing the already preexisting inheritance relationship that exists between canvases.) Perhaps you can comment on that PR?

I like #18854 a lot better. It gives you a path to from just a Figure walk your way up to building it a sibling in whatever scheme of canvas / manager / show / etc the user has put together.

I had thought about attaching the Backend object to FigureCanvas an friends, but then you can not re-use the classes between backends. Going the otherway and putting all of the parts on the FigureCanvas means with minimal sub-classing you can associate a custom manager to a given FigureCanvas.

Thinking a bit more about the toolbar discussion, I think having down-stream sub-class either the Manger or Toolbar classes is not a terrible pattern to suggest. We tend to think in terms of libraries and compos-ability (which makes sense given our interest in working at the library level!), but the cases where I have seen where there is significant toolbar customization have been domain specific applications (the buttons the added only made sense in a very narrow science context) where the lack of being able to compose with another packages modifications does not matter.

Closing in favor of #18854 where (as normal) @anntzer is a few steps ahead of me.