Actually, no... I don't think it's name mapping as such. I think what is happening is that you are getting a reference to an object, then you are doing something else, then you are going back to that object and, in that intervening interval, that object you had reference to was destroyed and recreated. The original handle to the object is invalid.
Hence the question of examining what's going on in Test 108... specifically, what line of code is getting the error and what is it expecting at that point in time. And, likewise, you need to double check that, whever is going on there, it's not going to be sensitive to what happened in Test 107.
One POSSIBLE scenario to investigate... and this is just a guess but it is an example of what COULD happen.
Test 107 grabs a reference to an object and throws it into something like a global variable or a project variable or something. Test 108 uses that same variable in it's code to reference the same object and, perhaps, if that reference isn't there, it refreshes it somehow (reassigns the variable, performs some other steps, etc).
However, Test 107 ends up doing something that actually destroys the object so that the reference is still there (variable is not NULL) but the underlying object is no longer valid. Test 108 sees the reference is not NULL and tries to use it only to find that the object was destroyed in the intermediate time.
Again..., this is a POSSIBLE scenario and, since we don't actually have your test cases here, should only be treated as a guess. The exercise of determining what EXACTLY is happening is left up to you to do the necessary leg work.
