You still seem a little confused about how these events work. Most of your events are redundant. I made some changes, try this project. You're just trying to match a Color object with a random frame for each Runnerz, right?
Remember ordinary events have a for-each built in to them. The event:
Every tick
-> Set runner X to runner.X + 1
is run by C2 like this:
Every tick
-> For each runner instance: set X to self.X + 1
See there's no need for a 'for each' condition - 'every tick' does the job fine.
Conditions also have a built in for each. The event:
Runner: X < 400
-> Set runner X to runner.X + 1
is actually run by C2 like this:
For each runner: if X < 400, remember this instance
-> For each remembered instance (all of the ones with X < 400): set X to Self.X + 1
You only ever need 'For each' when this built-in behavior isn't enough. One of those rare situations is when you're using the "Compare values" condition, because it does not pick anything for you. For example:
+ Compare values: Runner.X < 400
-> Set runner X to runner.X + 1
C2 runs the event like this:
Evaluate Runner.X. I'll just grab the first one because I don't know which one to use. Is Runner.X < 400? Yes. (note no objects have been remembered)
-> For each runner instance: (I haven't remembered any, so I'll run on all of them) Set Runner X to Runner.X + 1
Despite the event, all the runners move right. You could add a for-each to fix it - but it would be better just to use the "Compare X" condition!
Finally, to pair up objects, a neat trick is just to use
Every tick
-> Set colour position to (runner.X, runner.Y)
This pairs each colour with a runner. This is because C2 runs the event like this:
Every tick
-> For each colour instance: find a runner object paired with me. Now set my position to that X and Y.
This doesn't work with the 'set position to object' action! That's a bug, I'll see if I can fix for the next build.
In short, C2 is trying to do for-eaches and pairing everywhere for you. You just need to know how it works under the hood to take advantage. Hopefully the .capx above helps!
The containers system in Classic also fixes this issue, because it forces instance pairing. Destroying the objects is a bit of a hack in my example, but I guess it works. I'll add unique IDs (UIDs) for the next build - that enables another workaround.