We basically discovered that each and zip were the same function, but with slightly different treatment of the results. Both functions visit their arguments in the same order, but differ only in whether the resulting list of lists is flattened or not. And we realized that we'd end up with twice as many function names if we kept going down that path. Either that, or many of the constructs that return a list of lists would end up with one version but not the other. So I decided to invent "slice context" at that point, in which case the old each is just a zip in list context, while the old zip is now a zip in slice context.

The ordinary list behavior in every case is to flatten, which is what a Perl 5 programmer generally expects anyway. So map flattens its return lists, as does gather/take. But in slice context, each of these turns every returned sublist capture into a real subarray.

Any function that returns a list of lists can now let the user decide whether to flatten the top level or not, simply by returning a list of capture. This "let the user decide" meme is pervasive in Perl 6, and is also why the fail function may or may not throw an exception, depending on the caller's preferences. It's why all argument lists are captures, because we don't yet know how the user will bind the arguments, so we just decide that lazily (which by the way fixes the problems with Perl 5 prototypes).

The most basic syntax that returns list of captures is the semicolon separator when used below the statement level. So when you write zip(@a;@b;@c) you are passing a list of three captures to zip(), which, because it binds to a slice rather than a list, recognizes the semicolon boundaries. The primary benefit within subscripts is then that you can write zip(1,2,3; 4,5,6; 7,8,9) without worrying about parenthesizing each sublist.

For zip's arguments this may seem a bit weird, but the reason it's called slice context is that it really gets useful when you start subscripting multidimensional arrays, and you often want to specify lists in one of the dimensions, as in @array[0..10; @x; 1,4,9,16]. It was generalizing that context that made us realize it could be applied usefully to many list-of-list problems.

And that's why the specs do not mention each any more...