The major obstacle to acceptance of the Date & Darwen idea of inheritance is that it's not what most programmers mean when they talk about object-orientation. The definition of an "object" is the synthesis in a single entity of state and behavior. I have no objection to the judicious separation of these two things into i.e., structs or class methods, however a class with methods but no instance data does not define an object, and neither does a class with data but no methods. (Hmm, "Methods without data are empty, data without methods are blind" :^) This is why I'm saying that "implementation" covers all aspects of how a class does its business, including not just the data members, but the member functions as well. Now if all you want out of an object is its data, then subclassing is inappropriate; rather, you should simply pull what you need from the object and store it elsewhere, where you don't need to ensure that it won't be acted upon using its natural inherited behavior.
"The definition of an object"? I don't think there's any single formal, well-defined definition of what an object is. This is exactly why Date & Darwen explicitly avoid ever using the word object, and just talk about data types.
Now, it's certainly the case that many informal definitions of what an object is assume that it combines state and behavior. I'm not entirely opposed to this. I'm simply proposing that it might be advantageous to separate the inheritance mechanisms for state and behavior from each other. To a certain degree, this is possible in many languages, which allow you to inherit behavior (interfaces or a virtual parent class) without inheriting state.
What I'm speculating on is the possibility of inheriting state without behavior, which in theory could be done by inheriting from a class that only implemented "state-access/update" methods. I'm further speculating on the idea that a language that had different syntax and inheritance mechanisms for these two might be useful. For example, I might do "object->do_something" for behavior and "object.size" to access an attribute. And both of these would be valid ways to use the object. Furthermore, there'd be syntax for two kinds of inheritance, so we might do:
class TalkingSword : state -> Weapon /* inherits state from RPGObject
+class */ : behavior -> EdgedWeapon, Speaks;
