re: adding language to draw_text: the general discussion about extensibility of renderer API applies, i.e.

• if you're going to add language as a parameter to draw_text then it should be at least keyword-only.
• it's likely that the more maintainable API would likely to just embed language as part of fontproperties (it's not really different from e.g. font features, I'd think) and tell the backend to read that info.
• for draw_text we have actually more or less given up on having a "clean" renderer API because we pass the whole Text instance to draw_text (perPropagate mpl.text.Text instances to the backends and fix documentation #1081) anyways so perhaps backends that care could also just read that info off the Text instance. It feels a bit dirty, but heh... ("dirty" because we as well may just have a renderer API that'srenderer.draw_text(textobj) to start with...)

Side point regarding allowinglist[tuple[str, int, int]] as language setting: this may be a problem if one usessomelanguage[idx:] to set the language from an index up to the end of the string (whose length could technically be modified later, even though it's not clear this necessarily makes much practical sense). Likely you needlist[tuple[str, int, int | None]] (and then you may possibly support None (=0) for the start as well).

In the call a couple weeks ago, we decided to drop the newlanguage parameter todraw_text, because that already had amtext parameter which contained the wholeText object. This would avoid any signature introspection.

However, one followup is thatRenderer.get_text_width_height_descent wouldalso depend on font features/language settings, and really should get these passed through somehow as well.

I've added atext.language rcParam as discussed on the call last week.

Also added a What's new note, though as with the other PR, it won't show the difference untillibraqm is added.