It seems that I have managed to get a reproducible process for an
issue that has flummoxed a few other people over the past few months:
http://code.djangoproject.com/ticket/14642

In a nutshell, inline formset code (which I have relatively little
understanding of so far) is not protected from simultaneous edits of
related items. It's insidious because it probably won't happen if you
are the only user on the system testing your app in development. It's
only when you get to production and many people are working on the
same data. I can also confirm that this happens on the latest Django
1.3 rc1

I'm trying to go through the code now to find a way to patch it but my
main reason for coming to the developers list is this: What is Django
supposed to do in this case? As a user I can think of two possible
user expected behaviors: one would be that my changes overwrite the
previous submission. The second is that I am informed that my form was
invalid and hopefully the developers have given me a new form and
somehow preserved my submitted data. What is the correct behavior?

Procedural note:

You've changed the summary and focus of that ticket.

Do you have the same enviroment as the OP?
(i.e. using generic inlines and the 'Save as' button
functionality but without any multiple user simultaneous
interaction). Have you tried to reproduce it before
editing the ticket?

If not, you might be "stealing" a ticket instead of opening
a completely new one which would be the right thing to do.

Your description of the analysis of the issues doesn't show
you've taken in account OP's issue either it is not clear
both issues are the same.

Regards,

--
Ramiro Morales

(Sorry Ramiro, I think I replied directly to you instead of to the
group. Resending here)

Understood. I believed I was adding a testcase and expanding the scope
of the issue but it is certainly possible that they are two separate
causes. I will keep that in mind in the future and will certainly open
a new issue/revert this one here if everyone would prefer.

For what it is worth I was able to reproduce the exception using the
original reporter's code but only if I follow the process I outlined
in my report. I am still unsure as to what the correct behavior for
Django in this situation should be.

Actually I've just reproduced (using trunk) the situation reported by the OP:
Simple two-model generic foreign key plus generic inlines setup in the
admin app, activation and usage of the save as button and no need to
add a second browser window in the mix. A very simple
to prepare and reproduce setup.

The other users that added comments to the ticket before
loosely described their problem as not related to the admin inlines
at all rather with more low level model formsets; in any
case they don't provide enough details to be able to know if they
are really contributing to the isolation of the original issue or
simply landed in that ticket with a search and found something
similar in its symptoms to their own issues.

Because of this I'm going to revert your changes to the ticket
and I'd like to ask you to open another ticket and move
what you've found so far there.

We might be in presence of he same issue but I think
the divergence of initial conditions show it's too early
to be sure of that.

Thanks,

--
Ramiro Morales

OK, I opened a new ticket for my issue (http://code.djangoproject.com/
ticket/15574) and reverted the subject on the existing ticket #14642
to the original subject. I uploaded the test case I wrote to the new
issue and I'll look to create a test case for #14642 while I'm at it.
Thanks for the advice.

I still would like to get a design decision on what the appropriate
behavior of Django should be when an inline formset form is POSTed
which contains an inline item that has since been deleted on the
server.