Added.

For some reason in the C# version, the third argument is a List but using System.Collections.Generic; is not there by default

Don't be sorry. Fixed!

In C# tests, test named "ExBad5" has a useless trailing comma in the last grid row.
Sorry, but I had to point it out :)

This is an old kata, and consistency of tests and implementations was less regarded at that time. I don't think it is possible to change this without breaking old solutions, and in general the prevailing is opinion is to avoid it (breaking old and valid solution) as much as possible, for this reason one must cope with it.

Why is the tested input of type object and not int in C# ?

The description says "Note: Input will either be a positive integer (or a string for untyped languages)."
I feel like it's unnecessary for an 8 kyu to do parsing. C and C++ versions are int for example, seems fine.

I just added a LINQ based one liner solution that is 2D array compliant, with no extra methods/extensions, but I do have the same musing about the choice to use a 2D array; multidim arrays are usually a pain in the ass compared to jagged.. I was expecting the output to be [][] rather than [,]..

One option is to use C# to its fullest power and write a custom LINQ extension method that transforms any multidimensional array to a jagged one.

@hobovsky: My 2 cents: It's not just LINQ. There aren't that many languages with multidimensional array support like C#. The original kata and all other translations expect a jagged array as output. IMO the translation is not consistent with the original (and the other translations) without a good reason.(*) The output format limits the possible ways to solve this kata or forces using some unusual tricks.

(*) When C# supports jagged arrays and jagged arrays are the usual way, what is the point of using a construct specific to C# which is not consistent with the original? ¯\_(ツ)_/¯

Then I would say that this reasoning is backwards. Implementation should be driven by design, and not the other way round. Choosing an inferior interface only because it would allow you to use your favorite library is exactly reverse of how things should be done.

Linq is why peopple use C# here in the first place.

This is arguable. It would be also good to realize that Linq is just a tool and nothing else. It can be used where fit, and should not be used where it does not work.

Sorry, after reading my post it sure doesn't make any sense.
What I meant is that Linq in .NET only handles jagged arrays natively, and not multidimensional ones like here
You have to use extra tricks to use it (see https://stackoverflow.com/questions/18896150/c-sharp-linq-return-a-multidimensional-array-from-linq and the best answer's source)

This is why I'd argue that using jagged arrays as returned values would be better, as it's handled by Linq by default
What do you think ? Linq is why peopple use C# here in the first place. It's a bit of nitpicking though, I'll admit

I am not sure I understand the problem: all rows are of the same length, so the "rectangular" array seems a good fit? In a jagged array, you could have rows of different lengths, what does not make too much sense? If the table is always 10 rows long, and each row has 10 columns, then int[10,10] is better than an array of ten int[], each of potentially different length?

C# uses a rectangular array (int[n,x]) for some reason, I don't think this makes sense since the rows and columns are the same length.

Shouldn't it be a simple jagged array (int[n][]) ? I don't see any reason to use a rectangular one here.
It would also make Linq more accessible

Done, thanks!

First sentence in the description: Should have a space between "a" and "to"