Or lack direct applicability as we still didn't select a default OO style (minus - it's not helpful if a trivial one-line pattern requires 20 lines of interface glue to cope with both blessed hashes and blessed scalars).

What are you thinking of here? OO code in Perl shouldn't care whether an object is a blessed hash, a blessed scalar, a blessed nuisance, inside-out, upside-down, a Moose, a Mouse, or even a C pointer with a thin XS wrapper. You have an opaque reference. You call methods on it without worrying what it points to.

The only case I can immediately think of where this can legitimately fall down is when you inherit from someone else's object in a way that involves you trying to store additional private data inside their blessed data structure. But there are well-known ways to avoid that. And considering that code reuse through inheritance is a dodgy thing in the first place, the dodginess factor goes through the roof when you don't even control the code you're reusing!

Maybe there are other cases where well-written code can go wrong, but all I can say is that I've never yet encountered any problems in Perl that I could attribute to the lack of a single official method of implementing objects. I may well be missing something, but this seems to me to be one of those things that is more about Perl being conceptually messy, than about that messiness causing real problems in practice.