I'm not entirely sure that I understand what you mean by "allomorphic references". However the first design that comes to my mind is that Perl 6 should define what it looks like to refer directly to something in another language, and then there should be tools built to offer a translation service, translating the one language into another. If no translation layer exists, then things like errors are pretty much opaque to Perl. If a translation layer exists, then it handles things however you would like.

A thought: the translation layers should not just map classes, but should be able to add/detect useful metadata. For instance in translating Perl errors into Ruby or Python, it may be good to allow a Perl type to translate into a Ruby Class, and a Ruby Class to translate into a Perl Class with some extra metadata tagged on it (so that it falls into a type that would be translated back). This piece of complexity allows you to do as reasonable a job as is realistically possible in translating between 2 class hierarchies that divided things up in fundamentally incompatible ways.

Yes, this kind of approach would make those interfaces substantially more complex. But I think that the complexity is necessary.

A tangential thought that this discussion of translation brings to mind. I think that it is important for the Perl world to plan on some "best practices" for handling internationalization. (Documentation, error messages, etc.) The current CPAN works great..if you're willing to say that all programmers must speak English fluently. But I'm convinced that many people with scripting problems do not speak English as a first language, and I'd like to think that Perl will attempt to address their problems.