Perhaps use the word digit instead of number in the description. As Second segment must start with a number, followed by 2 letters. is ambiguous and could be mistakenly interpreted to mean a number of any length followed by two letters.

If the water consumption rate was changed, any method would have to be rewritten. The rate is not provided as a parameter here, thus we have no choice but to perform a calculation based on a constant in the code. I suppose it could be assigned to a variable for ease of changing later, but that is not a requirement of this kata.

The description says when the pile gets full of raked leaves, we have to burn the pile before we can continue to rake and When the burn pile is full, raking stops until conditions are right for burning the pile, but it doesn't explicitly say that the pile can't be burnt before it gets full. But the test cases assume that the pile is always full before a burn can happen. It is possible to fully rake the yard more times in some of the examples than the "correct" answer if you go ahead and burn what's in the non-full pile, plus the 1/4 of the yard that can be raked directly into the burn, rather than waiting until it is full and conditions are right every time.

It is never explicitly stated that the pair of numbers for the wall are the distance to the north and south walls respectively. And without the ascii illustrations, it's not even explained that the walls are all equally sized segments of the north and south walls. For a moment when starting to read it, I thought perhaps the room was an irregular polygon with a certain number of walls all closing in towards the centerpoint. You should make clear that you are describing a room with flat, unmoving east and west walls, and walls closing in at possibly different jagged distances, from the north and south. And none of the examples in the description describe a situation with unequal north and south walls at a given x coordinate, so without any other demonstration, it's entirely left to the reader to assume that the numbers in the pair represent north and south distances.

I somehow managed to overlook when first solving this that you wanted the pages in memory, and not the pages in the queue. Perhaps this is because, while you take special care to explain the order the pages appear in the queue (that the most recent arrival goes at the back of the queue and the oldest arrival is in front), you never discuss the order of the pages in memory at all, leaving it to be deduced from the example. Once I noticed the order of the pages shown was not in fact oldest in front, most recent in back, I realized my mistake, but perhaps you could explicitly say that the pages in memory are filled from start to end until all pages are filled, and then they are replaced, oldest first. Perhaps you can also put -1's in your example to make it extra clear that it is not the queue being depicted (which should be more obvious because, since the queue can't have duplicates, it definitely shouldn't have multiple -1's). You also might want to amend the Note that when a page is inserted in the memory, it stays at the same position until it is removed from the memory by a page fault. to mention that this applies both to the memory and to the queue being used to manage it. i.e., not only do current pages not change locations in memory, but recurrences of a page already in memory does not update its position in the queue.

The description is somewhat confusing, only clarified by the examples. It says:

Your task is to take a number and return it in its mid-endian format, putting the most significant couple of bytes in the middle and all the others around it, alternating left and right.

The moment you talk about "couples" of bytes, you introduce ambiguity when discussing endianness unless you explicitly state the ordering of the most significant and least significant byte within that couple. Perhaps instead you should simply say each byte, from most significant to least significant, alternates right then left?

The description says

cellscellscellscodecodecells
cellscellscellscodecodecells
cellscellscellscodecodecells
cellscellscellscodecodecells
cellscellscellscodecodecells
cellscellscellscodecodecells
cellscellscellscodecodecells
cellscellscellscodecodecells
cellscellscellscodecodecells
cellscellscellscodecadecells <- here it is! [9, 20]
cellscellscellscodecodecells
cellscellscellscodecodecells
cellscellscellscodecodecells
cellscellscellscodecodecells

But the tests expect the results to be returned in form [column, row], not [row, column].

Codewars needs a better range of options than just Very, Somewhat, and None. At a minimum, the addition of "this is infinitely dissatisfying; the mere existence of this Kata has made my life worse".

The example test cases had a typo in them: Assert.AreEqual("abcde", Kata.Assemble(new string[] {"abcde","abcde","abcbe"}));

I fixed it. It had the potential to be confusing to anyone solving this, because the description says that '#' should be used when it's not possible to determine the correct character, which would also apply if there are conflicting non-asterisk characters, even though that wasn't part of the original Kata design. Otherwise, looks good!

I'm sorry, B1ts, but you're wrong. The initial solution template for C# did indeed have Predicate<int> instead of Func<int, int> It is entirely possible to publish a Kata with a faulty template. I have fixed it.

What's with using System.Threading.Tasks; in the C# solution template? Is this a hint that we're expected to make our solution parallelizable?

The C# description says The input m will always be smaller than or equal to n (e.g., m <= n), but the tests generate cases where m > n.