It was more a case of needing to read the instructions 4 or 5 times, and then 2 or 3 times more after my code was written, to work out the bugs. Partly my fault, and partly just down to the concept of the kata, which is not easy to describe succinctly.

For what it's worth, here's a rewrite of the instructions.

- You have to do several runs. The depth is the number of runs you have to do.
- In every run you have to switch the direction. First run from left, next run from right. Next left...
Every run has these rules:
- You start at the first element (in the current direction).
- For each number X, find the remainder R when dividing it by the number of still unprocessed elements (including X).
- If the remainder R is less than or equal to 2, X goes directly into a new array.
- If the remainder R is greater than 2, copy a sub-array of the next R elements (starting from, and therefore including X) to the new array.
  Continue with the next element AFTER the copied elements.
- Every sub-array in the array is independent and is only one element for the progress through the array. 
  For every sub-array you have to follow the same rules for unflattening it.
  The direction of the run through a sub-array is always the same as in its parent run.

I don't know if it will seem clearer or not. Since we have both understood the mechanism of the kata we are maybe not in the best position to judge that.

This seems rather simple for 5 kyu?

Where is the problem? "remaining elements" is normal english. What did you not understand?

A little bit unfair to give a negative voting, only because you didn't understand the description at once. :-(

If you have hints and ideas for improving the description, it would be more constructive! :-)

More challenging to understand the instructions (what is meant by "remaining elements", and <3 / >2 confusion) than to code to the instructions.

Nice kata, thanx :)

It wasn't really clear to me, that you only unflatten sub-arrays if you meet them in the array, not if they are "taken". You might want to clarify that - or maybe I'm just slow. (Makes nicer code that you don't have to, anyway - so that's nice ;) )

Your solution is very short, well done!

I too had made a brute force for the 4x4. Which I generalized, and then thought I could use for this one. Well, that was going to take a while... So I optimized, and could easily solve the first example. But the next ones, not so much.

So back to the old drawing board - but that was just so much more satisfying when I found a clean way to do it.

Yes, I really liked this one. Good job. Even if I thought it was going to be a piece of cake after the 4x4, and wasn't :)