Fundamentally, there's no reason this couldn't be done. To work as most people would normally expect, you'd have to use a copy-on-write (COW) strategy.
That is, you have two children, each of which we expect to have what acts like its own copy of the parent object. As long as the parent objects of both contain the same values, the two can share access to the same object. Even though we conceptually have two separate objects, they both contain the same values, so accessing the same object (mostly--see below) acts the same as if we had two separate objects.
When one of the child objects attempts to change part (or all) of the data in the parent object, we have a problem though--if both children contain references to a common parent, changing a parent value in one child will also change that value in the other child--definitely not what we'd normally expect. To deal with that, we create separate copies of the parent in each child if and only if/when one or the other writes to the parent sub-object--that is, if one modifies a part from the parent, then (and only then) we create two separate copies, and modify one (but leave the other alone).
There are still some possible problems with this though. One deals with timing. Somebody might expect that creating a new object is fairly slow, and assigning to (for example) an int is fast. If we use copy on write, creating the new object can be faster, but the first assignment (even the most trivial) to the parent-part of a child object can be almost arbitrarily slow (i.e., can involve copying the entire parent object, which could be quite large).
Another possible violation of expectations could arise if you had two child objects being used in separate threads, and both sharing access to a single parent object. Just for example, on a NUMA machine, a user might expect that each thread would have "local" access to its parent object, but if the two threads were on separate nodes one could end up with a slower access to a remote node instead.
At the same time, I don't think such a feature would necessarily need to be reflected in the language specification. A language specification normally places requirements on the observable behavior of programs. The point of using something like a COW strategy would be that the observable behavior of a program is not affected. It's purely an implementation strategy that has no affect on the interface. The potential "problems" cited above (and possibly a few others) are basically examples of potential conflicts between what a language specification might define as "observable" behavior, and behavior a reasonably normal user of that language might think qualifies as "observable".