Well, n isn't exactly an index, so I suppose it's OK.

I wanted it to be consisted between all translations. This kata uses 64-bit type as n in all languages.
Besides, size_t type is just alias of unsigned long long on x64 machines and, hence we're using RAX in NASM, I can make an assumption that target machine is indeed x64.
Usually size_t is used for array indexes and that is exactly the main reason why it is used here.

OK, I've read the C standard again, it's not the easiest text to follow, but the invocations of rand look correct.
What about the type of n? It has the same dimension as length.

Thank you for the feedback.
I've changed the signature in sample tests and added static to solution function.

Also thanks for the help with how I should change description for NASM. None of the available tutorials said anything about how to change description for the new language. Good to know that it's even more complicated with NASM.

I really don't think that two calls to rand are undefined behaviour since only thing that is not guaranteed is the order of the execution of these calls, but it doesn't really matter for the logic of my code.

The signature of who_is_next in the sample tests is different from those in other places.
n is an index, so its type should be size_t.
The reference solution should be static, otherwise it can be used in users' solutions easily.

n - (rand() % last) + (rand() % last)

I'm not entirely sure, but I think 2 unsequenced calls to rand are undefined behavior.

Missing nasm example in the description. nasm language tags don't really work, so it should be added like

~~~if:nasm
...
~~~
~~~if-not:nasm
...
~~~

This is a big deal: without negative numbers (or unary minus), one can use a much, much simpler parser.

seems it's not consistent through all languages. I guess your version hs been updated with random tests.

Description should be changed to clarify that numbers can be negative.

number          ::= { digit } [ '.' digit { digit } ]

NASM translation added, please review ;)

I added the 142857 in a new "clarifying anti-example" section in the description in hopes of improving the understanding of this kata's requirements.
I resisted creating this out of concern that I was creating a "wall of text" that either won't get read or that otherwise discourages kata attempts.

My favorite kata on here are terse, deceptively simple and their solutions profoundly satisfying.

142857 is 5-parasitic but 142857 ends in 7 NOT with 5 as the title "n-parasitic ending in n" and the "Special Parasitic Numbers" section clearly calls out.

I think you should update test cases (at least those for C#) for base 10, because for n = 5 correct answer is 142857 not 102040816326530612244897959183673469387755, because 5 is special case and period of 5 / 49 isn't the smallest parasite number possible. For n = 5 correct answer is period of 1 / 7.