|Think about Loose Coupling|
Depends what you mean by "list". The problem is that most people have some rather specific definition of "list" in mind which often doesn't match some other definition of "list" that the person they are communicating with is using.
I suspect that the author of the documentation that you quoted was thinking specifically of a "list literal", that is, some parens around a bunch of scalar value expressions that are separated by commas, or thereabouts.
You appear to have silently extended this definition to include "list slices". Well, "list slices" happen to also return their last entry in a scalar context. But if you are going to include "list slices" in your definition of "list", then I don't see how you can exclude lots of other things from your list of "lists". For example, is a list assignment a list? Is an array a list? How about a hash? They are all lists to me (and are even talked about as lists in the standard documentation).
But there are a ton of things that people will think are "lists" and even that are called "lists" (even if we restrict ourselves just to the standard documentation that comes with Perl).
Actually, I try not to refer to anything as a "list" because of this false assumption that is common among Perl programmers that they know what a "Perl list" is. (: For the above things, I call them "operations that would return a list of scalar values if used in a list context". Note that that definition includes a lot of built-in functions (and non-build-in functions) but also covers lots of things that the quoted documentation seems to have overlooked.
Even if I stick to "list literals", I find the broad statement that you quoted to be misleading. In a list context ("a","b",@c) returns a list of scalar values. In a scalar context it doesn't return the last element of that list of values. It returns the last "element" of the "list literal" interpretted in a scalar context, that is, scalar(@c). I don't think "a list in a scalar context returns its last value" catches that idea very clearly.
In fact, if we look at the bit of documentation more closely in regard to my example, they must be referring to @a as a "value". Pretty strange terminology and, to me, it is even more indication that the author of the section was not being careful enough.
Apparently this is rant topic for the day. Tomorrow, "Whether or not to call srand() and how". (:- tye (but my friends call me "Tye")