That's just the point, we do not always know the consequences of manipulating the iterator. ;)

Whoever voted for "best practice" should be ashamed of themselves. YOU DO NOT MANIPULATE THE ITERATOR WITHIN A LOOP! Yes, this is all caps because a sentence like this justifies the use of all caps. :P
About the only thing worse than doing this would be to jump out of a loop with a goto.

It's a shame that the issue is known for over 4 months and still hasn't been fixed. Also what I really don't understand is why my solution didn't work even though it was EXACTLY THE SAME as one of the working solutions. WTH?!
After I forfeit this one I tried my solution again and this time it worked fine. Um, what? :(

More test cases needed, also should make use of double instead of int, especially when dealing with milliseconds. Also, the description is a bit unclear. "Past what?" was the first question I asked myself.
Oh, and maybe tell people to NOT use magic numbers when coding. ;)

I'll be bold and claim that this one CANNOT be solved in C#, since the test cases are too big. I tried many different approaches, some fast ones, some not so fast ones. It would ALWAYS time out for taking longer than 6000ms. I forfeit and copy pasted some of the solutions and guess what? NONE OF THEM would pass the test cases. Some would time out, some wouldn't work at all (error message for numbers > 9). This kata should be taken down for C#.

Thanks for this submission and the comments you left on your solution. I failed this one as I just couldn't get a solution that would work fast enough. I unlocked the solutions only to see code here that I've already tried (the obvious being modular division) but it still wouldn't process fast enough for me. What gives?

Should add a break once isOrdered is set to false to optimize it a little bit.

Yes, you have to manually include
using System;
using NUnit.Framework;
as the first lines in fixture.cs, or else the test cases won't compile.