upthorn, assigning to you as the coder of the persistent variables feature.
Do you think it makes sense or is feasible to implement some check for whether an acquired (or written) global variable is a unit and if yes, clear its underlying_id field ?
Other possible way would be to document it and require the simple workaround of wml coders. Since the engine normally tries to preserve that attribute as much as possible this doesn't seem to be such a bad idea.

A suitable workaround should be to clear the underlying_id field of units before transferring them to another campaign. That way their underlying_ids should get adjusted to match the new campaign they're in.

Anonymissimus, hopefully the following answers your two posts.

Summary: it does occur in a certain case, may possibly occur in others, and might just be a MP Campaign bug.

The duplicate underlying_id bug does occur without the umc author modifying it. However, this might classify as a MP Campaign Bug (which are currently unsupported)

It can (and does) occur under the following condition:

Any time someone stores units in persisent variables and unstores them in another game. (Might be limited to MP, keep reading.)

This has occured when I was writing my Custom Campaign add-on, and I added code to alter underlying_id specifically to prevent such collisions. (Maybe that means Custom Campaign is a "hacky modification" :D )
I do remeber hearing of at least one other add-on using persistence to allow a player to use their army again for an MP Campaign once they have completed it; this bug might show up there as well.

It might occur under the following conditions:

It's possible that this does not occur in SP, as SP has [side] persistence=yes; which might in it's opperation prevent such things from occuring in how the units are stored between scenarios (I'm not familar with that code to be sure)

In MP, [side] persistence=yes; does not work for any scenario which uses random maps (which is a seperate bug I have yet to draw up a report for, and classifies as an MP Campaign Bug) and add-ons like World Conquest and Random Campaign might have underlying_id collision problems occur because they need to resort to using [store_unit],[unstore_unit] to pass the army between scenarios. (Though there is some linking of scenarios, even though parts are broken, as such their operation is slightly different than those that unstore from a global persistent var.)
I say might occur here because I haven't observed it yet myself, the nature of the bug is such that you have to be paying attention for it, and if your recall list is long, (ie, 15+ units) it would be easy to miss one or two units dissappearing between scenarios) Though the post I linked to below suggests it's occurance in MP Campaigns

The question here is how it is possible that you can have the same underlying_id twice. Unless the wml/lua author does some hacky modification this must not be possible.