I see what you are saying. I think the Employee/Artist example i gave doesn't really hold up to what I was trying to express, but was more convenient than getting too contrived on a subject Im not 100% on. (not 25% on!)

So far I have been using a similar setup to what you suggest. Im not too clued-up on patterns, but it seems to be like the hasa relationship suggested by others?.
I find this kind of "orientation" simple to manage - it is DOM-ish and familiar. All objects inherit a common base-class for general introspection and delegation , then rely on their own class to provide their "individuality".

The problem i find with this, is that an objects "individuality" is purely based on its data - it is difficult to have dynamic behaviour, sensitive to both the environment the object is created in, and the relationship between (for example) caller() and $self at any given time.
If @ISA were an instance variable, then this could be realistically implemented. The class may provide a default - but time, context and environment could mutate it appropriately. As it stands, @ISA is per class, so the only way I can think of to hack it, would be something like

sub callMethod
{
    my $self = shift;
    my ($method, @args) = @_;
    
    # pseudo-code only ;)
    (defined( $self->{buddies}->{ caller() } ) ) ?
            unshift @ISA, "Behaviour::Informal" :
            unshift @ISA, "Behaviour::Guarded" ;
            
    my @return = $self->$method(@args) if $self->can($method);
    
    # hide what we just did from the rest of our class!
    shift @ISA;
    return @return;
}
[download]

I realise the limitations with the above code, but i guess its somewhat less abstract than the pseudo-existential waffle of "perspectives" ;)
Im pretty much out of my depth here, so perhaps I am just thrashing in comp.sci terminology?