This is not necessarily a bug, but unintuitive enough that I thought it's worth calling out.
I have a level (attached) where a stream of clones from the entrance all encounter a clone-triggerable proximity trap linked to activate a decoration trap (gives the clone a touque), but the link has a delay set, and moreover, the delay is such that the next incoming clone will trigger the proximity trap before the current clone's link delay has finished elapsing.
The intended effect is that each clone will get their touque one by one, N seconds after they come out.
However, if you try it out, what instead happens is that the next clone triggering the proximity trap will effectively reset the delay for all the previous triggered clones as well. So no one gets their touque while there are still clones coming out. Then after the last clone come out, and then N seconds more, and suddenly everyone gets their touques all at once. If you lower the entrance's spawn rate enough so that the link delay elapses before the next clone's triggering, then you'll get the intended effect.
Again, not necessarily a bug per se, but it took me by surprise enough to lead me to point out the behavior here (for v1.29 anyway).
A possible mitigation I'm going to try is to make duplicates of the proximity trap, and have it such that triggering one will disable itself and then enable the next one. Basically spread out the triggerings over several traps so that each copy has enough "breathing time" between triggerings to avoid the effect described above. Of course, in a multiplayer level since both the entrance spawn rate and the number of clones released are configurable, there will be some practical limit beyond which the workaround will break down (ie. the higher the spawn rate and/or the more number of clones released, the more duplicates you'll have to use).