Thank you for your post.
I am able to replicate the issue with FileMaker Pro 11.0v4 under Windows XP, Mac OS X 10.6.8 and Mac OS X 10.7.1. I have forwarded your post along with my findings to our Development and Testing departments for additional review.
Development is saying this is not an issue. The reasoning is if you edit a related record but don't commit, you haven't really made a modification yet. Since the change is made via the main record, that change is part of the main record's transaction. Deleting the record without committing is the same as deleting the transaction without committing it. It would be wrong to commit changes in other tables if the main record/transaction is deleted because those changes might result in the creation of orphaned child records. Also, if FileMaker tried to commit "related changes" even though the main record/transaction was deleted, what if the user didn't want to commit the related changes? The current behavior allows the user to click out/commit the changes and then delete the record.
Sorry, but can't agree with this statement:
It would be wrong to commit changes in other tables if the main record/transaction is deleted because those changes might result in the creation of orphaned child records.
That referential integrity issue is why we have the "delete records in this table when a record is deleted in the related table" option.
Still mulling over the rest of this as the data entry is modifying a different record in a different table.
If all relationships were of a strict Parent with primary key to Child with foreign key relationship, this would make more sense to me, but many relationships are based on more ephemeral and less strict relationships where the link between record in table A to record in table B is not the sole relationship involved and the records in the related table, in this case, are needed independently of whether or not the new record in the current layout is or is not retained.
At the very least, this should be clearly documented in Help.