If you try to memorize a big list of cases (whether you pejoratively label them "special" doesn't matter), then you are doing it wrong. This is the same mistake many people make with the precedence table.

Instead, understand why the cases are there and they are easy to remember. For both scalar context and operator precedence, there are a minority of exceptions that have little sense behind them (and most of those have both a reason why they "don't matter as much" and historic context that explains the imperfect design). The majority are well justified and thus easy to understand and remember.

If it isn't clear what the useful scalar value is for a particular operation, then reasonable responses include 1) looking up what the scalar return is in that case and why, 2) wondering why you are using scalar context in a way that doesn't make clear sense.

A really bad response is: consult a fundamentally flawed "model" to make a guess at what is returned and then either be surprised or pat yourself on the back and still not have any clue why that is the most useful thing to return (or, less often, why there isn't really an obvious answer and something more arbitrary got implemented or, rarest, why something other than the most useful value got implemented).

Yes, part of a correct model here is "it depends". Inventing an incorrect model, especially one as elaborate as "is it an array or is it a list?" tends to become, just so you can use it to make poorly-motivated guesses and avoid understanding how scalar context is useful in many cases, seems of dubious value at best. Certainly not enough value to justify the wrong answers it provides much less the confusion it leads to.

It's useful to have some default model to explain common behaviour.

A slice in scalar context is "common behavior"? I don't think so.