I think you are referring to the scenario in HORNETQ-782. Is that correct?
This case is a form of Problem A. The difference is that java.lang.Object is the shared super class, and the sun jdk is "shared.jar". I had commented on the issue that it was "near" invalid, since there isn't much use you can do with java.lang.Object. You could use reflection, but typing would be superior. Problem A is the "legitimate" version where you have a real sensible contract that works fine in the local case, not so great with serialization.
Both solutions will work in even in the strang java.lang.Object case. The difference mentioned above is that it's a choice between putting the burden on the developer or the implementer. Since we have JBoss Marshalling, which does all of the hard work, I think that burden is pretty small. I think the challenge in the HORNETQ case is just the protocol changes and handling older clients.