Yes you are right

No, it's not weird. You're not using the race's worth, that's why your code is wrong, read the description again.

Same sentiments here

the world will never know...

@carlsagan, tests are not buggy. Your code fails on this fixed test, returning 0:

[TestCase("b", 2)]

I think what happened in your case is that because it's random tests, it fails on one of the generated strings. And then when you try to debug by adding Console.WriteLine, you don't get the same case as the previous string. This might be caused by your function having wrong output, or the test cases actually having something wrong. Unfortunately, I can't check the C# test cases since I haven't done it in that lang.

I am wondering too

"don't think you need the aggregate function, just join the array into a string and long parse it" - Using Aggregate performs the same job as Parse will, without needing to allocate a string to do it

It's repeatedly adding 1 to n and then checking if the new n has all the same digits as the original n. It does this check by sorting the digits of the original, and sorting the digits of the new, and converting both to strings, and comparing the strings for equality. It's horrifically inefficient in every regard (a brute force approach, sorting and string alloc) and definitely shouldn't be marked as "best practices". I also wouldn't personally give it a "clever" vote. Try running it (fork it) to find an answer for the next number bigger than 109999999999999L.. It'll time out

I believ "2:yy" should be befor every "=:xx" since Char.toCode '2' is smaller then Char.toCode '='
in the case of equality with 2 "=:" then you sort with classic ascending alphabetical order.
i used 3 level of sorting

There were no restrictions in the conditions ¯\(ツ)/¯