• An operator imposes a context on its operands.
• Every operator decides what it returns based on context.
• An operator cannot return a list in scalar context.

Allow me to have those numbered for clearer reference:

1. An operator imposes a context on its operands.
2. Every operator decides what it returns based on context.
3. An operator cannot return a list in scalar context.

I think part of the problem with saying this is only three rules is that we're using what appears to be a mathematical representation but with slightly incompatible CS jargon. In CS jargon, the ($x,y) = ($foo, $bar) has one operator and two operands (both of which are groups of scalars (or "lists", if I may with JavaFan's permission used that term in its English definition. Yet in mathematics the words "operand" and "result" are not used quite the same as what rule #1 assumes. It fully appears to the naive that what we have there is a list as a result on the left, an operator in the middle, and a list as an operand on the right. That of course is not strictly what is happening, but you must clear up that misconception (rule 0, perhaps) before rule #1 hits its mark.

Be prepared for questions of infix, prefix, and postfix forms, of arity, of precedence of the assignment operators, and of associativity. Be prepared for when someone asks if the commutative, associative, and distributive properties apply to assignment. When the syntactic sugar makes something appear to be mathematical and you must point out that it is only closely related, people will come up with all sorts of odd questions to confirm what can be inferred from math to the language.

I don't see how someone who's not a CS student or graduate gets either abstraction for free. Many of the people who program in Perl have studied little CS, have studied it informally, or have studied none of it at all. If they already have taught themselves along one line of thinking, which happens to be the one the docs seem to reinforce, then asking them to throw that away in favor of what's easier for someone already trained in CS might be asking a bit much.

The abstraction you present may help someone more in the long run, and probably will if they ever dig that deeply. It may turn them off the language completely in the short term, though, or delay their study of the particular topic. If they learn to think about it in a way that lets them write software and can change how they think about it later, I do not see the harm. The biggest complaints I've seen against the approach FunkyMonk took in Re: Scalar context of slice to explaining this situation in Perl is that it can be potentially misleading and that it can waste time to learn something more than once in different terms. I'm not sure either is such a terrible thing. Waiting to understand the actual way it happens inside perl might waste time, too.

I would rather encourage someone to learn whichever explanation makes more sense to them, with the caveat that one (the "simple" one) requires more information beforehand and the other one (the "complex" one) requires even more of the same rule and exception handling later.