This is actually pretty complicated to explain. There's a sort of paradox in the event engine that in order to make events "just work" intuitively, there's actually a lot of pretty complex code!
newt is in the right direction with the "every tick" example. By default if you say "Sprite1: set X to Sprite2.X", it pairs them up. The event engine does this by what is internally called the SOL index. Think of this like the IID, but instead of being the index within all the instances, it's really the index within the currently picked instances only (aka the SOL).
So in the "Sprite1: set X to Sprite2.X" example, the event engine really runs an algorithm like this:
for each SOL1index in Sprite1 SOL:
--- get Sprite1 instance at SOL1index
--- get Sprite2 instance at SOL1index
--- set Sprite1 instance X to Sprite2 instance X
A similar algorithm is used for conditions, except the last step is "run condition using Sprite1 instance and Sprite2 instance". Note it only compares one instance against one other instance.
The key thing to note is SOL1index is also used as an index in to Sprite2's SOL (aka SOL2). When all instances are picked (as in the Every Tick example), SOL indices are effectively IIDs, and everything pairs up. However when you start picking instances, they no longer pair up.
The interesting thing about the capx is the condition is sort of backwards: in my mind I'd write "NPC: compare Target = Waypoint.ID", but instead it has "Waypoint: compare ID = NPC.Target". This means if any Waypoint does not have an NPC set to move towards it, it's not picked - and is removed from the SOL.
So in your first example you set NPC 1 target to 2. This means the waypoint with ID 1 fails the condition. It's also important to note that each instance only compares itself to one other instance, as per the algorithm above. So it fails the condition not because there are no NPCs with target value 1, but because the single paired NPC 1 instance did not match.
So waypoint ID 1 fails the condition and is un-picked, and no conditions mentioned NPC so they all remain picked. The NPC actions now run with pairing like this:
0: NPC0 - WP0
1: NPC1 - WP2
2: NPC2 - WP3
3: NPC3 - WP4
4: NPC4 - nothing
There are two interesting consequences of this:
1) surprisingly, NPC2 goes to WP3 even though its target value is 2. This is because:
a) all NPCs are picked - they all "met the condition" because no condition referenced them
b) WP1 was filtered out, and it ends up paired with WP3 via the SOL index - note the engine is ignoring instance values here, this is what's left behind by the condition
2) NPC4 goes to WP0. This is because the event engine implements wraparound for the SOL index - if it goes off the end, it wraps around back to the start.
Similarly if you edit NPC1 to have a Target of 0, WP1 fails the condition again, and the SOL ends up:
0: NPC0 - WP0
1: NPC1 - WP2
2: NPC2 - WP3
3: NPC3 - WP4
4: NPC4 - nothing
This is actually identical to the previous result. The reason is it's just another case where WP1 fails the condition, and everything else is the same.
Basically the best way to think about this is the event engine tries to pair instances together, but if you start picking instances, all bets are off - the pairing won't make sense any more. Also it might help to realise that once the condition has finished running, the instance variable values have no effect.
When you add "for each NPC", you force the event to run repeatedly with just one NPC picked. Since it forces the whole event to run repeatedly with just one NPC instance, it works as expected. Note since the Waypoint condition runs an implicit for-each loop, this actually acts as a nested loop comparing every instance of NPC against every instance of Waypoint. So you actually compare all combinations, whereas before it only compares against a paired instance - which is more or less a random instance if you have conditions picking them.