How to Copy/Paste Symbols containing Flash Components without creating copies of the Assets

Question

I think the fl.controls components can be useful if you want to do things the way they are built. However, I'm running into a serious usability issue whenever I need to have slightly different "versions" of a symbol that contains the same component.
For example, I have a question view that has 9 rows of Radio Buttons in it (each row is inside a symbol that manages the state of the Radio Buttons). The Question View symbol would be in the Library in Question Templates>QuestionType>ThisTypeOfQuestionView. For my demo, I want a version of that that has only 6 rows of Radio Buttons. So I copy my Question View Symbol to Instructions>QuestionType.
This has added a folder called QuestionTemplates>QuestionType with my ThisTypeOfQuestionView in it, along with a new copy of the RadioButtonRowSymbol and folders that are copies of the Component Assets needed for RadioButton (and guaranteed not to work, since you can only have only one asset with the same linkage id).  I rename my Question View to DemoThisTypeOfQuestionView and move it into the root of Instructions>QuestionType. Fixing the copy of RadioButtonRowSymbol is easy--I just drop the copy of QuestionTemplates back on QuestionTemplates.
But the repair process for all the extra component assets involves opening every folder in the nonfunctional Component Assets copy to its lowest level and dropping the contents onto the appropriate "real" component assets folder and selecting "replace" each time. This is tedious and fraught with error.
Is there a setting somewhere I can select that leaves pointers to assets in copied symbols pointing to the same place, while still keeping base class definitions in place?

Answer 1

I can't say for sure but I believe because skinning is a very important part of components, the duplication was a necessary evil. I believe they favored the slight file size increase and skin customization.
The problem runs just as deep in code completion. You'd expect completion when creating a copy of an object but it's just not sophisticated enough because of the dynamic and custom nature of the code. In the same way you can provide multiple custom skins to duplicated components you can provide custom class variants so it doesn't inflect the completion because you never really know what the user really intends. I believe this is a limit of that, not knowing that you don't care to customize the duplicates.