Item using empty index list would result to display the entire list

This is an example:
Item Bug - Snap

However:
Item Bug - Support

And if we do this, the result is correct:

Item bug support 2

And of course, if the index list is not empty, it's working, so this is just an edge case scenario.

I think this boils down to that this should report an empty list and not the full list
untitled script pic (32)

Yes @cymplecy, I agree with you.

Probably we should change this, you're right. It's not precisely a bug because the specified behavior is ambiguous. If you interpret the empty list as being an empty list of numbers, then it should do what you're suggesting. But if you interpret it as an empty list of lists of numbers, then each missing sublist is permissive rather than restrictive. Here's an unambiguous example of how that works:

Since the selector list isn't empty, it's unambiguously a list of lists. Since the data list is two-dimensional, the selector list should be of length 2, where each sublist selects along the corresponding dimension. The missing second sublist is interpreted as allowing all indices along that dimension. That's obviously what the user intends -- otherwise the result of ITEM would be empty.

It took us three tries to agree on a design for hyperblock ITEM. For lists of lists, we ended up doing essentially what APL's item selector does. But before we thought about multidimensional item selection we first did a straightforward hyperization of the original scalar ITEM. This is different from the APL behavior, which essentially treats a flat list of numbers as a singleton list containing that list, so the list of numbers applies to the first dimension of the data. So we ended up treating a flat list of numbers as a special case. This all works quite well, as long as the index list isn't entirely empty, so that we don't know whether it's intended as an empty flat list or an empty list of lists.

But you're clearly right about what the user expects us to do in this case, so we should make a special case within the special case. :~)

P.S. Is there a name for a misbehavior of this sort? It's not a bug, as explained above, but it's not a misfeature either, since we didn't decide to make it behave this way.