Well, I could think of a possibility how this CAN happen with crappy coded pointers (which would be in SM then)...
If you have an array named Text like ["Title", "Hello World"] and you hardcode shit like
Print Text[1];
because you basically want to print out "Hello World", it works as long as no one touches your array.
But if someone goes like
Text.Insert(1, "Random Bullshit");
and then you call
Print Text[1];
assuming you'll get your "Hello World" you'll just get "Random Bullshit".
So what I'm saying is: maybe SM sets the value for a standard field that is queued somewhere, always at the same position, to change its value. Now GE: S has more fields causing the field that is called normally to change its place in the queue, the pointer now goes to ge_teamplay instead. It doesn't break anything yet, if the value isn't really changed.
Let's assume ge_teamplay is a property, so there's additional code carried out when its value is assigned:
public ge_teamplay{ get {return m_ge_teamplay;} set {m_ge_teamplay = value; doSomeStuff();}}
this is where it gets interesting.(if m_ge_teamplay is the private field storing the variable) Because basically doSomeStuff() can reset the scores or be anything. SM doesn't know about, it just sets a value - apparently for no reason, because the teamplay mode isn't activated when it wasn't before or deactivated when it was activated before.
Then a workaround would be to check if (m_ge_teamplay == value) and skip that part or break;.
Nonetheless it'd be a strange behaviour for SM to set a variable it doesn't need to by requesting a collection of all fields.