Add a config setting that allows us to switch the default map language between the page language and 'local'. The latter would let us use the new Kartotherian code to emulate the pre-i18n behavior.
I also just realized: we've had code propagating the lang attribute in production for a few weeks. That means we already have static maps in the parser cache whose URLs contain e.g. ?lang=fr. These will magically become i18ned after the i18n deployment unless they are reparsed (a reparse would change it to ?lang=local).
I'm actually going back and forth between 1) a string variable that can take 'local' but also 'en' or 'fr' and a special value (null, or 'pageLanguage') that means page content language; and 2) a more restrictive boolean flag (i.e. $wgKartographerMapsInContentLanguage) that would default to false (translated into lang=local) and could be enabled to mean page content language. The ability to specify any string like 'en' or 'fr' can be seen as a feature or an open door to mistakes and weird configuration we would rather not have.
That the bigger issue. Regardless of the variable used for rollout (custom source or custom lang), all pages with maps on wikis with static maps will be stale until edited. There must be a way around that. Has no one ever wished to deploy a parser update and have it fix all pages using feature X? Is it completely unreasonable to loop on all pages with Category:Page_with_maps and ?action=purge ?