To avoid this bug, uncheck the Propagate primary key relationship property of the parent entity. Unfortunately, if the parent entity is not abstract, this solution will not be applicable: you'll probably have to modify the relationship modeling itself.
Strange Locking Behavior
It would appear that there is, in our opinion, some bugs related to optimistic locking within a single EOF stack. Essentially what it boils down to is that it appears that the update database operation that is created as a result of a call to .saveChanges() is backed by the EODatabaseContext snapshot and NOT the "working" snapshot inside in the EO in the editing context it came from. What this means is that while changes are not merged until you .unlock() and .lock() under normal circumstances, because the underlying snapshot that EOF diffs your changes against on save is the DBC snapshot, it's effectively inadvertently "merged" on commit. That is to say that if another EC makes changes and saves, then you make different changes and save, you will blow away their changes with no sign of an optimistic locking exception because your snapshot IS their snapshot now (meaning, it looks like just you are overwriting their changes, versus the reality of the situation that you are actually conflicting with their changes). After discussing this some, we believe that if the update operation used a version of the EO's backing snapshot instead that these weird behaviors would be fixed and it would behave exactly like a normal conflicting update if you were in two EOF stacks. The current behavior smells of bug, but I'm curious if anyone a dissenting opinion on the topic. It's certainly really complicated and nasty down in that code, so it's possible there's some crazy justifiable reason for it.
Here are two diagrams of examples. Left side is EC 1, right side is EC 2, purple is the state of the EO in EC1 at various points, yellow is the state of the same EO in EC2 at various points.
Here's the "blow-away-other-changes-in-the-EO" workflow:
Here's the "no optimistic lock exception" example: