This bug is more subtle than it first appears.  As far as I've been able
to figure out, there is in fact no way to reliably detect that there is
non-format text after the format specifier short of completely parsing
the format specifier.  I went through several possibilities and found a
counter example for each that shows it would introduce new bugs:

See if last character of formatted string is different from last char of
formatter: format('%s', 'things') would then incorrectly be an error.

Make sure last character of format string is a valid format character: 
format('%fx', a) would be valid, but it has a 'x' on the end which is
not part of the format string.  (The suggested patch has a false
negative in this case as well.)

Check for a decimal in the formatted string and if it didn't get
transformed, complain:  format('%s', '1.234') would fail incorrectly.

One could argue that at least \n and \r should be checked for since the
output from those cases is least obviously "wrong", but I don't think
that is a strong argument.  The extra control character is almost as
"visible" in the output as the trailing 'x' would be in the above
example, and the effects of the trailing x are equally mysterious.

To fix this correctly would require reimplementing format parsing in the
locale module, which would be a maintenance headache.

I'm inclined to close this "won't fix", unless someone can come up with
a heuristic that won't give false positives or false negatives.