With both ApplyMRU and ApplyMRD, does one commit before the other runs?

Question

This is related to another thread at How to stop insert of new row in tabular form if it's also being deleted I wanted to ask this question separately, however, for broader understanding.
I have a tabular form configured so that if a user clicks on "Delete Checked Rows", it fires the ApplyMRU process and then the ApplyMRD process. (This is mainly so that other edits are not lost when deleting some rows -- see the other thread for more on this use case.)
Both processes run, as I can see edits and deletions happening when the page returns. But it appears as though the ApplyMRU process doesn't actually commit its changes to the session before ApplyMRD runs, because it won't operate on the same record. Is that true?
Here's why I think that:
1) User clicks "Add Another Row" to insert a new row.
2) User enters some information in that row.
3) User then checks that row (say they changed their mind and don't want to enter it after all), and clicks on "Delete Checked Names".
The new row gets inserted (when ApplyMRU fires), but not deleted (when ApplyMRD fires). Other checked rows, however, do delete. This reproduces in both ApEx 3.2 and in ApEx 4.0, with the new, client-side addRow() replacing the old implementation.
Is this expected behavior?

Answer 1

Nicolette - ah, I think you nailed it. The PK is being created in the trigger. So it's not in the form when it is submitted, but is created after ApplyMRU runs. There doesn't appear to be any way to return that information back to the session state, since it could span multiple rows.
It hadn't occurred to me that the delete would be using the PK, but of course, that now seems obvious in hindsight.
I've found a fix for this -- it seems a bit circuitous, and if anyone knows of a better way, I'd be interested in hearing it.
Here's what I did:
1) Create a validation that looks for rows that are checked (marked for deletion) AND do not have a PK set (just added to form), and override the value of some other, non-PK field to some dummy value. You can't override the PK field, or it results in a "Current version of data in database has changed" error. This also handles the case where some non-nullable field is null.
2) Add a process that runs after ApplyMRD (when MRD button is pressed), and deletes all records with this dummy value, as well as any auditing table entries with that dummy value, if applicable.
Ironically, this solution is almost identical to the one I described in the other thread, and I might not have even run into this issue, had I not mistakenly coded my validation to fire when the request is MUTLIROWDELETE. Oops. :)
Thanks for the help!