I highly doubt that. Coroutines are actually internal compiler generated classes. Calling a coroutine / generator method is nothing different from calling any other method. Though coroutines / generators do not run their code but return a new instance of that internal class which represents your coroutine code as a state machine. It’s highly unlikely that generators from different classes would clash in any way. This is not even Unity related as the yield keyword which is responsible for that is 100% C#. So I would say you misinterpreted your results and your issue is elsewhere.
Note that you can run coroutines on different MonoBehaviours since the actual IEnumerator object that is returned is a closure / object instance which can be run by any active and enabled MonoBehaviour. Maybe you disabled the MonoBehaviour that was running the coroutine which would terminate the coroutine?
You could even run coroutines cross-over. So even this does work:
public class ClassA : MonoBehaviour
{
public ClassB b;
protected void Start() {
StartCoroutine(b.DoSomething());
}
public IEnumerator DoSomething()
{ ... }
}
public class ClassB : MonoBehaviour
{
public ClassA a
protected void Start() {
StartCoroutine(a.DoSomething());
}
public IEnumerator DoSomething()
{ ... }
}
Here the Start of ClassA would start a coroutine on its own instance but runs coroutine DoSomething from instance b. ClassB on the other hand runs the coroutine DoSomething of “a” on his instance. As I said, the actual “DoSomething” method literally has only one line of code which is a return statement which returns a new instance of the internal statemachine class. It’s very very unlikely that C# would mess that up.
Note that you can write your own IEnumerator classes and pass them to StartCoroutine. Unity doesn’t care what that class is you pass in. As long as it’s implementing the IEnumerator interface it works. That means you can even use a List as “coroutine”, though that would be pretty useless ^^.
List<object> stuff = new List<object> {null, null, new WaitForSeconds(5), null };
StartCoroutine(stuff.GetEnumerator());
This would start a coroutine that first waits 2 frames, then waits 5 seconds and then another frame until it finishes. Of course there’s no code in between the “yields” so it’s completely useless. But it does work anyways.
Whatever your issue was, I’m 99.99% sure it’s not an issue with the coroutine / generator method itself. If the compiler would mess those fundamental things up, nothing would ever work.
So you hijacked this thread for your own different issue? 
Because that’s what the OP was about.
Note that you can actually check what each generator returns. Use GetType on the object it returns before passing it to any StartCoroutine call. See the type name of that internal class (which is quite weird as you will see). StartCoroutine doesn’t care and doesn’t even know the name of the generator method. All it gets is the statemachine that was created by the generator method.
IEnumerator obj = DoSomething(); // create statemachine object
StartCoroutine(obj); // hand this instance to Unity to start it as a coroutine.
So the name of the method can’t have an influence here. The string version is different as it can only start coroutines which are defined in the same class. Also you can’t pass arguments to the generator method. The string version in general is a bad idea.
For the future, please start a separate thread and include more details about your issue, how your setup looks like and what your exact results are. Saying “it doesn’t work” is insufficient. I’m also very sceptical about @grahamlynch_1 's statement
. When I reload the scene, the colliders stop signaling the OnCollisionEnter2D function.