We would label this a tricky gotcha but truth be told BUT if it got you you must have had more time on your hands than sense.

A recent announcement from Revelation  explained that the <> syntax has been updated - and that due to huge improvements in <>< processing speeds " you can continue using the familiar “<>” syntax for sequential dynamic array processing without needing to rewrite code using LOOP/REMOVE or LOOP/[] parsing patterns.". 

Historically nobody in their right mind would have processed the 65,536th element of a dynamic array using <>. If they wanted to get there they'd have used loop/remove. When the Revelation compiler was originally written, the maximum row size was 64K - so the maximum possible populated columns was 32K. So to speed up processing, the compiler replaced a < N > reference to a special opcode optimised for such extractions. Using < N, N > and < N, N, N > don't redirect to this special opcode, redirecting to the EXTRACT opcode instead.

All well and good except for one slight snag. Remember the 64K limit? Well, then it made sense to store the value for the <> opcode as an unsigned 32 bit integer. Trouble is, that can only accommodate 64K.

So what happens if you try and extract from an array where N is > 64K?

A picture allegedly speaks louder than words