Bjorn, can you give a motivation of this use case?  Can the use case be 
satisfied with the TRANSIENT + SYSTEM_ID policies? 

Either way, I have reduced the severity of the bug.

Bjorn provided the motivation for this use case: he is using the
POA::activate_object() to generate the id when registering the servant
for the first time.  He records this id in permanent storage.  For
subsequent reactivations, he uses the same object id from permanent
storage and calls POA::activate_object_with_id(). This gives him
persistent, system generated ids.

This can be implemented in TAO's POA similar to how the USER_ID and
PERSISTENT policy combination is handled.  The only difference will be
that in this case the id will come from a GUID generator rather than
from the user.

Irfan, do you have more info about this, maybe we can tackle then this one with 
the POArefactoring?

Thinking a little more about this, I concluded that assigned Object
Ids must only be unique across all instantiations of the same POA and
not all POAs.  Therefore, GUID might be overkill here and the POA
timestamp might suffice.  My suggestion is to extend the Key_Generator
so that it adds the POA timestamp to the created key.

Reassigned