As #231 states, the current detection method makes the traffic lights quite unstable. The control box detects lights within a range rather than link to them, and everytime you open the gui it resets and need to be set up again. Quitting the world may reset it as well according to the case.
Can the control box actually link to the lights via a number or coordinate system, or just simply hard code the timing?

I don't follow what you mean here. Yes, the control box resets, but it doesn't change the light operation at all unless you hit the Confirm button. So once you link the lights you're good to go.

Well, currently opening the control box is like calling the existing lights to a meeting, tell them what to do, and forget about it. There is no way of knowing what delay is one of the lights on. When theres a new light in the system, you need to call another meeting and say what they have to do all over again.
It would be better to have a control box with a stationary delay sequence, and you link traffic lights to it, so you dont have to set it every time theres a new light.

For example, you have a box labeled A and a light labeled 1. In the box gui, you can link 1 to this specific box. When theres another light labeled 2, you can just add 2 in the box rather than reset 1 and 2 again.
This system will also allow different delays within a small range.

Making lights selectable is rather hard to do in a GUI. That being said, I can, and likely should, make the GUI initialize to the state of the control box when opened rather than resetting. That way if you were to place or move a light, you'd just go back to the control box, re-scan, and hit confirm without needing to modify any other settings. In your analogy, it'd be giving someone who missed the meeting the minutes rather than calling another meeting to bring them into the loop.

That would be great. Make the system look more stable rather than a temporary fix

Corrected in V15.9.0.