Maybe document that map value is function parameter index.

This could probably warn, I don't think there are any valid use cases for any of these functions with too-few parameters. Can you come up with a plausible case with any of the existing functions or some theoretical future function where the formatting string could be optional?

(Even if we can, we could change the map to <string, wild> and let you specify either an integer for "sane function with reasonable behavior and exactly one format string" or a dictionary of options for "special function which can be called with zero/more-than-one format string".)

This is pretty clever.

Since xsprintf() doesn't support everything that sprintf() does (like %3$d) it will miss issues with a few unusual format strings that sprintf() can handle but xsprintf() can not. However, AFAIK we don't use any of these features anywhere except in translations. I think we're fairly permissive about the parsing, so it should only have false negatives (except maybe %'%d for a %-padded integer? But that's such a ridiculous edge case that I'm not concerned about getting it wrong).

Specifically, I'd expect these cases to be wrong:

// False negative? We *could* catch this statically (but seems reasonable not to).
sprintf('%17$s', 'quack');

// False positive? This is technically correct as written (just ridiculous).
sprintf("%'%6.6d", 123);

Neither case seems important to me.