If you want to "outlaw" wantarray then this just leads to having to outlaw returning anything but a scalar.

    return @x;
    # same as
    return wantarray ? @x : 0+@x;

    return( ..., $y );
    # same as
    return wantarray ? ( ..., $y ) : $y;
[download]

Well, actually, there is one alternative to that (well, it uses wantarray but I think you'll agree that it honors the spirit of your desire to highly discourage the use of wantarray):

    croak( "This only makes sense in a list context!" )
        if  ! wantarray;
    # ...
    return @list;
[download]

Note that I am not saying that it is crazy to want to discourage the use of wantarray (in spirit). One can make some good points about why it can be a good idea to just always return a reference to an array instead of returning a list of values. And one can make some good points about making scalar context fatal when you have a function that really wants to return a list.

Though I also don't find it hard to imagine cases where always returning a reference to an array would be annoying. Returning a list can often be convenient. Yes, the only difference is the need to add @{ ... }, but those three characters can get pretty obnoxious if you have to sprinkle them all over your code.

So I can certainly imagine cases where you want to "normally" return a convinient list of values but you also want to allow for the occasional usage of getting a reference (perhaps because only occasionally the list is so large that the inefficiency of copying some big list actually matters). Yes, that leads to some specific opportunities for specific types of mistakes and thus has some disadvantages. But I'm not convinced that those disadvantages always trump the potential advantages. I think it certainly calls for some caution, but the amount of caution feels more like a style choice than something deserving of the "Considered Harmful" label.

Similarly, I can easily imagine cases where you very often just want the one simple item of data but you also want to allow for getting much more data. This is how a ton of built-ins work, for example, caller. And I don't see the trade-offs here as obviously always winning in one direction or the other and certainly not one side winning to the point of the other side being "Considered Harmful".

My style choice is to pay attention to the cases where an expression that usually gives a simple scalar would lead to errors if it instead returned a list of not-exactly-one items and to pay attention to interfaces that confusingly jump between returning a scalar or not (such as CGI's param() method and some regex constructs).

Most context-aware interfaces in Perl are a net win, in my experience. But it is a good point that one should consider the potential for confusion when implementing such and have some confidence that it is worth it.

As for the several recommendations of Contextual::Return, I have to disagree. That module appears to have been implemented in a way that suffers significantly from ETOOMUCHMAGIC and I happily avoid it and encourage others to as well.