Review "String incrementer"

[hobovsky]

The kata String incrementer could use some improvements:

• 5 pending issues
• 5 translations waiting for a review
• missing test cases allowing faulty solutions to pass
• inconsistencies between languages
  • Some languages reportedly generate inputs with digits only at the end and nowhere else. Tests for inputs like "a1bc2" are missing.
  • Some languages generate only short sequences of digits (see below)

I could fix the kata, (and use this opportunity to collect some samples for my library of snippets ;) ) but first it would have to be decided:

• Alphabet of the input string: some solutions are reported to break if an input would be like "ab-123", because it would be parsed as a negative number and produce "ab-122". Similar issue can be caused by a character used as a decimal point. Question: is a hyphen, a dot, or any characters other than [a-zA-Z0-9], a valid input?
• Some languages (Rust, idk about others) are reported to generate inputs with numbers which do not fit into built-in numeric types, and solutions like "find numeric tail -> cut it off -> parse to int -> increment -> stringify" fail on third step. For other languages, this kind of solution works. Question: should there be inputs with numbers not fitting into built-in types, like abc + "123" * 100?
  I would say yes, inputs should contain potentially large numbers. The argument that some languages have bigint and this would make solutions inconsistent between languages does not buy me, because I would just blame it on qualities of languages, and not on the problem itself. Python users are just lucky guys.

It would be also nice to figure out what are potentially interesting inputs. For now, I got:

• regular case, like "abc12"
• no digits at all: "abc"
• carry causing an overflow: "ab99"
• leading zeros: "abc0042", and leading zeros overwritten by a carry: "ab099", "abc0099"`
• only digit, no other chars: "123", "99", "099"
• long sequences of digits, if agreed to be included: "abc" + "123".repeat(100)
• non-digit characters tripping up solutions based on parsing: "abc-123", "abc12.3"`, if agreed to be included.
• inputs with digits not only at the tail: "ab123c456"

Something else I am missing?

[hobovsky]

Another idea: remove the kata, replace it with a new one, with additional requirement of handling all occurrences of digit string except the final one (i.e. for input "1ab23cd04e-56gh99" would be "2ab24cd05e-57gh100".