Software engineering teachers will tell you that you should avoid copying code. Why? Because if there is a bug in the copied code, when you fix the bug, you have to visit many places to apply the fix. But you should copy code when the original function is likely to change in the future and your new code segment would not be happy with that future change.
Inheritance of classes is a language feature that developed to address this issue. Each child class "copies" the functions from its parent and then overrides certain functions. For any non-overridden function, if the parent implementation is changed, the child is changed. For any overridden function, if the child implementation does not call the parent implementation, then changes to the parent implementation do not affect the child.
But suppose the parent implementation is a case structure on some integer value and the child class wants to do something special in each of the frames. Assume that refactoring the parent class is out of the question -- that may have come from some third party over which the developer of the child class has no control. The child class cannot override the individual frames of the case structure. The child must override the entire function, have its own case structure for the special values, and then call the parent. This works, but it means at runtime, the program wastes time doing the comparison operation twice. This is a simple case with trivial duplicated effort, but more complex versions can be constructed. And all of this presumes that the function in question is marked as dynamic dispatch in the first place.
Now, consider source code control. Developer Alpha writes a function and submits it to the code repository. Developer Beta branches the code repository, syncs the function, edits it, and checks in the modified version. Now Alpha revises the original. Beta can use various merge tools to integrate changes from one branch into the other. When Beta does the integration, he/she may accept changes, may reject changes or may bring them in with modifications.
What possibilities exist for a language syntax that allows a developer to specify, as part of the VI, the rules for integrating changes from another VI? In other words, suppose we had a way to create VI Dog1 from scratch, and then create VI Dog2 using Dog1 as a template (which we can do today) but have Dog2 remember that it came from Dog1. Then we could make edits to Dog2. Thereafter, if anyone edits Dog1, Dog2 loads and is a broken VI until the developer does a merge operation to accept/reject/modify the edits made to Dog1. As an editor feature, that would be (relatively) easy to do --- Dog2 just needs to remember Dog1 and have stored enough memory about Dog1's panel and diagram and VI Properties such that when Dog2 loads into memory, it can compare its memory against the Dog1 on disk and break itself if Dog1 has been edited since the last integration.
But suppose we went further and specified on the diagram/panel/properties of Dog2 what regions should be handled how. In other words, some portions of Dog2 could be marked as "If Dog1 changes in this region, just update these portions automatically" or "ignore any edits made to Dog1 in this region" or "Ask me how to handle any changes in the code and break the VI until I answer." The regions would likely have to be structure boundaries since arbitrary regions it might be hard to say whether a given edit was inside or outside (since physical position on the diagram has no semantic meaning in LabVIEW, knowing how to group new code would seem to require LV to have AI-like understanding of the purpose and association of new code), but perhaps there is a way to solve this.
Going down this road might extricate code reuse from the complicating topic of inheritance and class association. While such association provides many other benefits, I find it occassionally desirable to have a more broad mechanism for code reuse. Something like an arbitrary "copy this code to here, but keep aware of any changes to the original" feature might help encourage code reuse without creating the pain of, "Oh, you'll have to refactor that if you want it to work."
