The symptom is as described in the title

To reproduce reliably:

• create a package with 1 object, 1 version of it, 2 langs. Check what if the main language set for the object within its xml description in the package file
• create a 2nd eZ site where the object does not exist, where both of the used languages exist, but where the language that is the object's initial one is 2nd in the list of additional languages
• import package

The rationale:

• ezcontentobject::unserialize creates the object and its version 1 in the main lang of the object as found in package, then calls ezcontenobjecversion::unserialize
• this second method thinks instead that the object has been created in the main language of the site, so when it tries to add the remaining languages, it looses one

The fix: please see attachments for a patch. NB: patched files are from ezp 406, as the client that has been experiencing this is stuck at that version.

The good: there are other unexpected behaviours that have been apparently fixed by the patch above, such as some objects being created with no name when they are imported twice and the second time the option 'keep existing and create new' is chosen. So there might be a couple of related open issues that get closed as a bonus in one fell swoop.