I did answer your question (by saying that I avoid being tricky.) I don't code my modules particularly defensively. It's too tricky. You can get sick to your stomach worrying about every contingency. I take what I believe to be a rather Perlish approach: I give you enough rope to hang yourself and the three people closest to you. I.e. For the most part, I assume you know what you are doing. If you are going to call $obj->foo(new_value()), then I trust you know what new_value() is going to give you in list context. And, I trust that you know what context it's being called in.

Now, if I wrote new_value() then you probably don't have much to worry about because I avoid being tricky. In that case, you could be pretty confident that new_value() wouldn't be context dependent. Either it would (always) return a scalar, or it would (always) return a list.

For what it's worth, this is a relatively new philosophy for me. Like, within the last year or so. For instance, I used to write separate get/set accessors all much of the time but I can't recall even one single circumstance where it actually helped me or a coworker. Great theory. Limited applicability. (In my experience, anyway.) I think there's lots of that around.

Now watch me get bit by a bug like this tomorrow, right? But, then my tests will fail, I'll find the bug, fix it, and it'll all be in a day's work.

-sauoq
"My two cents aren't worth a dime.";

I was hit by just such a bug once. I expected a single value to be returned but received none. It completely threw me off. It's not the first time either - I've done the same thing when making hash contents.