I consider "not hard-coding method selection" a fine benefit, especially since what class a method actually comes from is an implementation detail that the user of the object shouldn't be bothered with much less be relying upon.

Okay, I see where you are coming from. I guess that reflects how little use I make of Perl's OO. It was my expectation that taking a reference to a method would do whatever method resolution was required. I even tried it out:

C:\test>p1
use threads;;
{ 
    package t1; 
    sub new{ bless [], $_[ 0 ] }; 
    sub method{ print __PACKAGE__ . ": @_" } 
};;
{ 
    package t2; 
    our @ISA = 't1'; 
    sub method2{ print __PACKAGE__ . ": @_" } 
};;

$o = t2->new;;
print $o;;
t2=ARRAY(0x22b00c)

$o->method2( 1 .. 5 );;
t2: t2=ARRAY(0x22b00c) 1 2 3 4 5

$o->method( 1 .. 5 );;
t1: t2=ARRAY(0x22b00c) 1 2 3 4 5

print \&t2::method;;
CODE(0x22afac)
[download]

Of course the problem was I didn't look closely enough at that coderef to realise that it had a autovivfied a coderef for an inherited method. If I had tried invoking it:

\&t2::method->( 1 .. 5 );;
[Undefined subroutine &t2::method called at (eval 13) line 1
[download]

but what is worse, having taken that reference to the inherited method, it permentantly screws up the method resolution:

$o->method( 1 .. 5 );;
[Undefined subroutine &t2::method called at (eval 14) line 1
[download]

Nasty!

This is certainly the case in other OO languages I used that support first class functions and OO. I don't recall ever having a problem passing a method around in Smalltalk, D, Q, Clean, Mozart, Ocaml, .... Even C++ has delegates these days.

Is it surprising that Perl OO and threads don't mix well, when Perl OO is so fragile?

/me will wait patiently for Perl6 before I get heavily into writing OO Perl methinks.