$entity_form[#op] does not reflect the operation actually being performed

Also, I assume from the way this works that there's sort of a third state: editing an entity that's now saved in the form (so not new, as in the form is populated with data) but hasn't yet been added to the database (so still sort of new, as in, don't do any database queries based on the data).

That falls under "edit".

A normal add (node page just loaded, add form opened), should have #op sets to "add" normally.

It's still an edit.
In general, I don't think the entity form should ever care about #op, or go digging in the db. But I won't try to prevent anyone from shooting themselves in the foot :)

Do we have any issue here then? Or was it just about the edge case?

It's about the inner form.

And I don't know how it can be wrong:

if ($form_state['inline_entity_form'][$ief_id]['form'] == 'add') {
        $element['form']['#op'] = 'add';

Re-opening. I'm still experiencing this issue, even in dev.

Editing and saving another variation while the form to add a new variation is open can cause the new variation to be saved prematurely.

Steps to Reproduce

1. Open the node add form for product displays (/node/add/product-display).
2. Add a new variation to the product display, either by creating one or selecting an existing variation.
3. Add a new variation by clicking "Add a new variation".
4. Fill-out all of the variation details but do not save the new variation.
5. Click the "Edit" button next to the variation added in #2 for editing.
6. Click the "Save variation" button on the variation added in #2 that was opened in #5.
7. Click the "Save variation" button on the variation added in #3.

Expected Results
The product display will have two variations -- the one added in #2, and the one started in #3.

Actual Results
The product display has three variations -- the one added in #2, and two copies of the one added in #3. Saving the product display results in a SQL constraint violation.

If I debug the code, it looks like inline_entity_form_process_entity_form() is invoked twice when the edit form is saved, once for the edit form, and a second time for the add form, even though only the edit form was really saved. And, in each case, "op" matches the button of the form being processed rather than the name of the real button that was clicked (i.e. when the function is processing the edit form, "op" is "edit"; then, when it processes the add form in the same request, "op" is suddenly "add").

Attached is a patch that corrects the following issues:

• Having both a variation edit form and variation add form open would cause the variation in the add form to be saved prematurely when the edit form was saved.
• Having multiple variation edit forms open would cause all variations to be saved prematurely when any edit form was saved.

One thought: my patch doesn't actually make #op more useful, it just doesn't rely on it as the only way to tell what form is being submitted.

Revised the patch -- IEF wasn't saving any entities that were open for editing when the overall node edit form was saved.

One more try: this fixes an issue where variations open for editing could be saved prematurely when a new variation was added.

This version also makes the conditional a bit easier to read by storing values in variables.

This will be handled in #2032649: Rework inline form submission.