What is the different between "transient" and "persistent" lifespan policies 
for CORBA object incarnations?  How does the ORB assign IOR's during execution 
in each case, using System versus User generated ID's (4 total cases)?  For 
all cases, what if the incarnation order changes, will the objects be assigned 
the appropriate IORs?  If so, how will the ORB know what is appropriate?

Transient objects exist only during the existance of the creating process, 
while persistent objects continue to exist after the creating process ends, and 
are able to be reused in subsequent processes. 

More information is available here: http://www.cs.wustl.edu/~schmidt/PDF/C++-
report-col12.pdf

> What is the different between "transient" and "persistent" lifespan
> policies for CORBA object incarnations?

From <a href="http://www.amazon.com/exec/obidos/ASIN/0201379279/qid=1024384189/sr=2-2/ref=sr_2_2/103-3577237-0954259">"Advanced
CORBA Programming with C++"</a> by Michi Henning and Steve Vinoski:

   "The lifetime of a transient object is bounded by the lifetime of
   the POA in which it is created."

   "CORBA objects which can live beyond any particular process in
which
   they are created or activated are called persistent objects."

> How does the ORB assign IOR's during execution in each case, using
> System versus User generated ID's (4 total cases)?

IORs contain a "Repository Identifier" followed by a series of
"profiles" which describe alternative mechanisms for contacting the
object.  For purposes of simplicity I'll presume that you have a
single IIOP style endpoint configured.  In this case the IOR would
contain a single profile.  Inside the profile, the "object key"
uniquely identifies the object within the POA.

Here is how object keys are constructed for each of the cases you
specify:

> TRANSIENT LifespanPolicy, SYSTEM_ID IdAssignment Policy

This is a common usage pattern.  The object key is uniquely generated
in a POA dependent way.  The POA might use a simple counter, for
example.

> TRANSIENT LifespanPolicy, USER_ID IdAssignment Policy

This is not a common usage pattern, usually transient object have
system assigned ids.  It may be useful for debugging (or other
related system task) to assign more meaningful ids, even though
the object will not persist after the POA has terminated.

You can create an explicit reference with the
POA::create_reference_with_id() function.

> PERSISTENT LifespanPolicy, SYSTEM_ID IdAssignment Policy

This is not a recommend usage pattern, usually persistent objects have
user significant ids (for example a database unique key) so the
servant can be incarnated "around" some particular state data.

> PERSISTENT LifespanPolicy, USER_ID IdAssignment Policy

This is a common usage pattern.  Using the create_reference_with_id
function mentioned previously you can choose the id assigned to
a particular object.

> For all cases, what if the incarnation order changes, will the
> objects be assigned the appropriate IORs? If so, how will the ORB
> know what is appropriate?

Not exactly sure what your question is concerned with here.

In the case of TRANSIENT lifespan objects it does not matter what id
they are specifically assigned as long as the IOR uniquely "addresses"
the desired object.  Incarnation order should not change that binding.

For PERSISTENT lifespan objects, the IOR does not depend on order
at all, it depends on the ids that the server application chooses.
As long as the basis for these ids is order invariant there should
be no difference in IORs based on object incarnation order.