You have a point.
I was thinking that maybe we should just add a neutral state for mode p or n or even just replace the instant response with an f so that the reaction on p or n is not given.
d= digital, f = floating point, n = negative step, p= positive step.
d, f , n and p all have an absolute floating point value between 0 and 1 or exactly 0 and 1 as part of their message. I think this value should always be send right after connection. P and N should be send as f. d should be send as d. This way we make sure that there is a unified rule for sending data. This makes sure that at any point a controlling action will cause an expected reaction. If we would introduce options to chose from, it could generate more confusion then it could solve. Because you never would know what you get, when you draw a line.
I see another point need to be taken care of and that is what happens when the connection is disconnected.
Imagine a robotic arm that is placed on position 0.5. If we started originally on position 0 then connected intentionally a knob to it that moves the arm to position 0.5. We are aware of the knob controlling the arm and expect its change of position. If we disconnect the arm anytime later it would go back to maybe an unexpected position since we might not even be aware what the line is actually connected to in the first place? Should it stay in place? Should it go back to 0?However with a light, it should maybe just turn off again as being "not in use".
I think we can formulate a clear rules for when one thing is controlling another thing, but when the thing is left alone by it self, it should be set back to what the creator thought is rightfully designed. Therefore we will need to add a default state to an IO-Point. This default state will be returned to in case the connection is lost. This however requires that the origin and the destination point keep a record of all links and that the reality editor sends links and deleted links to both and not just the origin.
Further down this is also very useful for data verification, where the destination only accepts data signed with the ID of the active link... Anyhow. Its a bit of a plan we would need to spend some time on. For now point 1 can be implemented easily (or @Carsten you already have the code?). Point 2 needs some more thoughts.