...you really want to look into is Perl6's object system with its traits model.

I have had several passes at thinking through how they are going to work, including this one. I like the concept a lot--all the power of MI without the nightmare that MI usually is in practice. And without the "everything inherits from everything" imposssibly deep inheritance trees that usually result.

I like contextuality in Perl5, I'm not sure it is really necessary, and I sometimes wonder if we couldn't have done just as well without it...

Your not the first person who's expressed that opinion here. S'funny, but I still see context awareness as (one of) the major, new (to me) contributions that Perl has given to programming. I'm completely happy to see it not only persist, but be extended. The overloading thing is an orthoganal issue here--it's just one way of using it. Powerful, but orthoganal.

What really started (ressurected) this thought process was a recent p6i post. Basically, Dan noted that in Parrot, the same mechanism that is used to provide for Multi-method dispath (that I think is destined to become very important in P6), means that calls to a subroutine, and returns from a subroutine, are essentially identical. Which, he goes on to suggest means that as well as MMD, we could have MMR (multi-method return) and all that is required is some HLL syntax to make use of this.

Whilst the thread goes on to discuss various more or less humerous uses for this, the thought crossed my mind that actually no HLL construct is required. All it would need is for an under-the-covers use of the enhanced wantarray to determine the return context and use that to MMR the appropriate representation of the thing being returned.

In effect, simply extending the current contextual awarness that allows me to write:

my $thing = 3.5;
print $array[ $thing ];
my $test =  'Some text' . $thing;
[download]

all without having to perform casts or any other machinations.

Extending this context awareness to user defined datatypes (objects) could allow the author of the class to (for example), add subroutines to his class (by some well known naming convention perhaps) along the lines of:

sub ^asText {
   my $self = shift;
   return sprintf "...", $self.attr1, $self.attr2...
}

sub ^asAnimal {
    my $self = shift; 
    return $self.Animal;
}
[download]

Then, whenever an object returns itself, the appropriate value is returned with the compiler determining which method is called to provide the result. If no method is provided for the context into which the value is being returned, then an exception is raised. If the return context is just scalar, then the base reference is returned.

It would remove the need for every method to test the return context and do the right thing. It allows new type conversions to be added later by the provision of a single new method. Everything else remains the same, but if any existing method is called in a context of the new type, it does the right thing.

I'm probably moving in directions that even TheDamian has the sense to steer clear of, but then I don't have the responsibility to see all the possible outcomes. Still, the idea seems immensely useful to me. But then it would, wouldn't it :)

Absolutely it is useful and there is dead cool stuff you can do with it. It's just easy to overdo. I do think it is essential to have because it makes it possible to actually extend the language. It allows you to create new basic data types that behave sensibly or conceal complexity behind the "interface" of a simple data type (think tie). It just shouldn't be used on the application logic level — too much magic is a nightmare.

I don't know how much sense that makes; I lack the vocabulary to verbalize my objection clearly.

Makeshifts last the longest.