Now I understand what you're asking. You're actually dealing with some interesting stuff here, but I think that most of the concern is a theoretical non-issue, but in practice it is an issue, but I think we're looking at it slightly differently. For example, your initial code doesn't work:

sub foo(ARRAY $bar) {...}

# later
foo(Bar->new);
[download]

That breaks immediately because &foo is expecting an ARRAY, not an object of class Bar. It's an easy fix:

sub foo(Bar $bar) {...}

Now it doesn't matter how someone implements Bar internally. However, there is one (false) objection and one very real objection. The false objection is this:

sub foo(Bar $bar) {
    print $bar->[3];
}
[download]

Obviously, violating encapsulation is going to cause problems regardless of whether or not method signatures are implemented. The real problem, however, and I think this is what you're getting at, lies in this:

my $parser = HTML::TokeParser->new(\$html);

sub foo(ARRAY $token) {...}

foo($parser->get_token) {...}
[download]

HTML::TokeParser returns array references. However, what if someone wants to use HTML::TokeParser::Simple? That module blesses the references. As a result, it is no longer a drop-in replacement. I am forced to alter the above code. (And this just highlighted a bug in my code that I'll have to fix ASAP -- darn.)