It's worth noting that this part of the description:

The only condition where implementing multiple different interfaces is mutually exclusive is if the two (or more) interfaces in question share a public method with the exact same name. In that particular case, if you implement both such interfaces at once, you will receive a Fatal error (since the "Diamond Problem" would arise which would create a conflict).

is not (or no longer) correct. As long as both methods follow signature compatibility rules, a class can implement two interfaces describing methods with the same name.

So the two interfaces in the exercise that overlap are actually compatible, as the methods are identical.

Issue with the PHP tests:

These incorrectly replace multiple consecutive input or output characters (, & .) with just a single putchar / getchar call.

This is incorrect, as while reading multiple bytes from input would only store the last, it would still consume multiple bytes.

Same goes for the output: the written character would be the same each time, but it would still be written twice.

(The interpreter in the tests would print Helo, World!, with just a single 'l', for example).

I could get my solution to pass by implementing the same error, but that is obviously not right.

Edit: Just noticed hotdonkey already reported this 9 months ago...

In the PHP version, the random tests will occasionally pop up an empty string instead of a number, combined with an error:

Undefined array key ""

Stacktrace that is supplied with the code goes to the tests, not to the kata-code:

/workspace/default/tests/AddFunctionTest.php:68
/workspace/default/tests/AddFunctionTest.php:53
/workspace/default/tests/AddFunctionTest.php:145
/workspace/default/tests/AddFunctionTest.php:30

My code handles empty strings as zero, but the tests still fail, as an exception is thrown.

The tests for the PHP version use single quotes (') to enclose the 99-bottles string, but do use '\n' in an attempt to render newlines.
However, \n is only parsed in double-quoted strings, so the song is returned as one big string containing literal \n throughout.

This obviously causes valid solutions to fail, and forces you to mimic the incorrect syntax.

It looks like the tests for this Kata have expected and actual results reversed.

So if the function returns X when it should be Y, the test says 'expected collection contained X' and 'actual collection contained Y'

The instructions don't specify if total_count and total_amount should be all payments, or all payments made to either Jon or Mike

As the test database currently only has those two entries in staff, the results are the same, and both versions will pass the tests. But the corresponding queries are different, so it seems like an oversight.

Wow. I just checked wikipedia, and you're absolutely right, it's under the 'additional constraints' section.

Every newspaper sudoku I've ever solved had that rule... Amazing.

Am I the only one who spent lots of time debugging their solution, only to finally notice that the requirements omit the standard Sudoku requirement concerning the diagonals also being complete sets?