There is a CProcessSessionstate objected created for every session (mapped and owned in sessionstates table).
There is only 1 per client (ip:port), mapped in the processlookup table.

Now, when one is created, then another, the 2nd will replace the 1st in the processlookup table (both will exists in the sessionstates table). The 2nd (newer) will track the old sessionid.

The 1st should be stopping by this stage, but the onClose from MP may not have been seen/or processed yet.

The 2nd stop _could_ beat the 1st in theory (but remember same client and had to grab same *unused* port).. 

To the Dali/MP onClose mechanism, the two stops are indistinguishable, the 1st stop seen, will stop the 1st start, regardless of whether due to a race, it was really triggered by the 2nd terminating client..

That is true if onClose() was the trigger (see idtostop = s->dequeuePreviousSessionId()) - BUT if it was a clean exit and MSR_STOP_SESSION called stopSession() - then...you're right.. I'll need to be careful to spot that the CProcessSessionState has other pending older sessionId's - and adjust accordingly.