Some well-defined things that can be worked on semi-independantly.
basic object system
The on-disk/in-memory representation of objects. (Should be modularised, different systems will want to use different approaches.)
Abstract/concrete objects.
Inheritence.
Field set/get (with atomic commits).
method runtime environment
This handles calling a method of an object. First it needs to determine what code to run, based on the capabilities of the system etc. Then run the method, using an interface appropriate to its implementation language, etc. Then get its result to be sent back.
sandbox
Implement a sandbox system, using eg, xen, and an interface to it that handles dispatching calls to untrusted methods to the sandbox, and trusted methods to the unsandboxed system.
ipc
Define a top-level interface, and do one implementation of that interface.
object replication code
This will be used both in moving an object around, and in replicating an object back to its home server, so that it can teleport back home if its current host dies. Might also be used in clustering. So it needs to be bandwidth efficient and robust and quick.
object identity verification
Part of the object reference system is a way to make note of an object, and be able to verify its identity later. Identity is a hard problem, and preventing an object from assuming several identities is probably out of scope. All that's really needed is a cryptographically secure, unspoofable or replayable way for an object to prove its identity. Signing its reference url with its private key could do (doesn't prevent replay though?).
There might need to be an identity broker function provided by the server, so that objects identify themselves upon entering a server, and the server can be queried for the identity.
method trust system
Handles determining if a method is trusted enough to allow it to run or not. (And decide if it runs in the sandbox or as a fully trusted method.)
This basically involves signing methods, and chains of trust.