Thanks! The description is now much clearer.

I will try to ask you to reconsider the condition again, but it would be much better if someone offered their version of the condition, otherwise we will just look for a needle in a haystack of a good solution.

Its easy to understand if you think of it like that:
for '123' next number would be 4;
for '1234567891' next number would be 1234567892;
and so on

IMO kata should return -1 if there is no solution within limits.

And include boundary test cases like:

test("999999999", 999999999);
test("1000000000", -1);  

yes, you are right, and in trying to get rid of the wrong decision, I forgot about my own conditions of the game. The problem will be resolved as soon as possible.

Changing the requirements was the wrong solution. Test suites should not take more than 20 consecutive numbers to concatenate, and if the first number is < 1e7, the string would have been < 140 characters.

The C test suite broke the kata. This is why you have to document the internal requirements of your test suite, and check that translations do not break them before approving.

Did you read

Numbers will never be truncated.

? The string isn't split up into digits, it's split up into numbers.

Not a kata issue. Closing.

This description is incredibly unclear.
How are we supposed to know if the input string can be split into single digits or two digits or not split at all?

"123" -> [1, 2, 3] -> 1
"1234567891" -> [1234567891] -> 1234567891

There's no explanation of why the two examples above are being split up differently.