To be honest I don't know why we expose the template backend as a "real" backend, but heh.
I wouldn't bother with docs unless someone shows me a real backend that can implement print_foo() without walking the Figure tree...

How is this preventing a unbound local?

The unbound local comes from the fact that previously, FigureCanvasTemplate.print_foo() did not figure.draw(renderer) (which I argue is unrealistic of any non-trivial drawer), whereas get_renderer() works by overriding figure.draw() to immediately throw ("goto") back to the caller and propagating the renderer out of the call stack. Now print_foo() does call figure.draw(renderer) and everyone is happy.

With the caveat that I don't know the codebase, it seems to me that UnboundLocals need to be fixed in the code structure itself and should not be allowed to happen, regardless of what a canvas should do vs actually does.

I also agree with @timhoffm that a test should be added, especially since based on comments in #17730 skimage might move to Agg for this check, which means we wouldn't be implicitly testing this for you in the future. 😬

Got rid of the UnboundLocalError (in favor of a RuntimeError). Someone else gets to write the test if you really want it... (I'd think we should just run a full test suite against all of backend_template (which is completely untested) if we really want to support that, rather than doing so in a piecemeal fashion).

Pushed a second commit that fixes #17744. May be better to rewrite _get_output_canvas() to be a context-manager that auto-restores the original canvas at exit, but let's keep that for later (also, name suggestions would be welcome).

Oh, I forgot about the testing stuff, oh well.