I haven't developed this scenario myself, but this seems possible.
If you want to do this it's best to create two relationships. You primary 1-1 relationship, owned by both entities. Assuming A is the parent entity, you'll have to create a second relationship 1-* owned by entity B. That second relationship is to track the history.
You can setup an before commit action that creates a copy of entity B, with an association to .
Depending on your other criteria in your application, you'll have to think about creating a copy of B and use that as the history or creating a copy of B and using that as the new current object.
Copying B for historical purposes is probably the most efficient since any relationship from object C or D will still point to the current object B. Also the owner and changedby will always be correct, the owner of the historical B is the person making the change. But you can also decide to this differently.
As a side node it is possible to retrieve the previous value of an attribute, that way you don't have to find your current object in your database. Just take a look at the Java code in the audit trail module, that tracks and compares the current and previous value.