Its useful to distinguish between objects that are downloaded and executed in the client, and objects which are executed remotely, with a local stub provided for binding to the remote object.
CORBA and ILU provide examples of how clients linking to remote objects can be made to work with language independent bindings. Messages are translated from the local format into a canonical on-the-wire format then translated back at the other machine to that system's language bindings. This can work equally well for binding message calls between two languages on the same machine. I am interested in the potential for using HTTPng to make access to remotely executing objects as easy and as widespread as HTTP and CGI are today.
As for "inlined" objects (ones which are copied to the client and locally executed). Language independence could be offered through URLS. Say a program written in one language wants to send NEW to an object class written in another, the trick is to specify the class using a URL. A system supplied function takes, the URL and any parameters supplied with the message, then contacts the remote server.
The server either returns the code for the object class or a stub for binding to a remote object. The language used for the code is determined via normal HTTP negotiation. When the class or stub is received by the client, it provides a language to language binding as required.
To get this kind of thing off the ground we need to standardize the canonical form for bindings, e.g. something like CORBA's IDL.