Just to be clear to anyone who reads this, here's the situation:
The user created a cluster typedef. Then he created a VI with an instance of that typedef on its panel; on its diagram, he created static references to controls *inside* the typedef instance.
I think LabVIEW did the correct thing. That is not same necessarily as the *expected* thing. Let's see if we can talk this through and identify if there's a better behavior possible. I don't think there is, but many minds can see solutions one cannot.
Consider... if you had renamed one of those controls inside the cluster, you'd want the property nodes to update, right? A cluster of "{A, B, C}" that you rename to "{A, D, C}", you'd expect a property node linked to B would change to be linked to D. And, indeed, LabVIEW does that.
So that's correct behavior.
If you had "{A, B, C}" and you change the labels of two of them to be "{B, A, C}", you also want the property nodes to update. And, indeed, they do.
So that's correct behavior.
Well, that's what happened here. From the caller VI's point of view, you did a massive rename operation, and the property nodes correctly followed suit. Each one matched up with the control that was in the index position it used before.
The obvious response: "Well, a rename and a reorder are not the same operation and LabVIEW should modify caller's differently."
The problem is that LabVIEW cannot assume that all callers are in memory when the edit is made. A caller may load long after the edit has been made, and all callers need to update in the same way regardless of whether they were in memory or not. So... the edit is made. The caller loads. All the caller knows is the before and after state of the typedef. It doesn't know anything about how the edit was made -- it may not even be the same machine where the edit was made. So what can it do? Well, either LabVIEW could use name matching OR LabVIEW could use index matching, but it cannot do both. In order to be smart about the edit, it would have to know what edit was made, and the typedefs do not have that kind of versioning record.
Could we add that kind of versioning record? We could -- the private data control of LabVIEW classes record the kind of edit that was made. Classes did it to be able to manage the data mutation of flattened strings between class versions. Would that be desirable for typedefs? I'm honestly not sure. On the negative side, it can become a significant weight for LV classes, and typedefs are much more broadly used. On the positive side, it would help more situations than just this one -- reordering items in a typedef'd enum vs renaming items in a typedef'd enum, for example.
Regardless, we do not have that record today. And without that record, LabVIEW has to pick one behavior and go with it. And I suspect that because reordering elements is much rarer than renaming, the decision was made to use the indexes to line back up.
I suppose another option is that we could say if the name AND the index do not match then always break the caller VI and force users to manually update all such nodes. That seems less helpful, but perhaps higher safety.
So, that's the reason for the behavior. It's not a bug. It's a feature. Just not a feature you wanted, I'm afraid.
