I think it might cause slight confusion if some parts of the object (i.e. some base or sub-base) are shared with other objects. When you modify a key that is stored in the base object and it gets set in the object itsself like a4u said above, then the structure of the object gets compromised and it can not be known where a key may be found when enumerating? Please correct me if I'm understanding something wrong here. I'm also not sure how this is treated when there is an object stored under the key and variables are added/removed from the object. Is a copy of the object stored in the instance of the class, or is it still shared in all instances? I'll try to write an example of this later if my argumentation seems unclear.The premise of your question seems to be that such a decision was consciously made. I never seriously considered cloning as an option (and I'm slightly curious about why anyone would). Keep in mind that the base mechanism was designed back in 2009, and the class definition syntax was intended purely as syntax sugar around the existing design. That said, actual run-time inheritence seems much more logical to me than "inheritence" by cloning, and is also more flexible.
While we're at this topic, were there technical reasons why you decided to use the base mechanism instead of creating a (shallow?) copy? Or was it a design decision?
Edit: I think it might help to avoid this at least somewhat if the member variables were declared when an instance of the obejct is created, as opposed to declaring them in the class object itself. This behavior is used by C# (see here: <!-- m -->http://msdn.microsof...y/ms173118.aspx<!-- m --> ).
My point is mostly that the "new" keyword carries the meaning of creating a new instance, without shared components.