🚀 go-pugleaf

Mr. Solo and Mr. Van Dyke, 
The points you both raise seem to be part of the Holy Grail of technical writing; that is, modularity and reuse. This approach is much more complex than simply having some publishing tool with a few features. Adobe does need to reflect on what enhancements to make to FM but cross references in text insets imported by reference should not be one of them. 

Just consider that importing by reference exists to allow the referenced object to be modified elsewhere and then automatically included and updated when a book is generated. Under this concept, putting any form of cross reference in such a text inset is a contradiction of good practice in information engineering. 

Cross references are a bit like GOTOs in programming - bad practice because they're difficult to maintain and lead to unmaintanable code. But X-refs are necessary because there is rarely time or resources to effectively engineer writing products. In addition, X-refs have an adverse effect on the usability of a written product so they should be used as sparingly as possible. 

The role of the tech writer appears to me to be that of the information engineer who has to achieve the best compromise between the input information available and it's rate of change, the time and resources available to pull the technical information together into reader useful information, and the usability/accessibility of that information. Under these difficult circumstances there is always considerable pressure to reuse existing material and make extensive use of X-refs. It could be that your circumstances oblige you to make this tactical choice, but it is not a good choice since it creates a potentially error prone documentation process. If you're working as individuals and nobody else will ever need to take over these publications, perhaps your choice can be arguably accepted. 

I cannot agree that the issues you have raised are FrameMaker problems. The issues are much more complex than that and go to the heart of the "copy or reference" conundrum. Perhaps the fact that the available shrink-wrapped tools do not support what you're trying to do should have been a flag to cause you to consider whether your choices are workable rather than cause you to question the validity of the tools. A few companies I have worked with have spent many years and millions of dollars to build the tools to allow writers to do what you seem to have chosen to attempt with a thousand dollar shrink wrapped package. Often these implementations have created more confusion than helped. This simply because providing the tool was not accompanied with a well defined philosophy as to how and when to use such an option. Giving people sophisticated hammers and chisels simply will not make those people into Henry Moore clones. 

I whole hearted agree with Arnis's statement: 
"You have to look at completely different model of publishing and maintaining 
your documentation." 

This is especially true when one of you mentioned that you did not know how such tactical choices would be handled by downstream processes such as WebWorks. In these circumstances there is only one principle to follow - KISS - Keep It Simple Sirs. While I'm in an analogous frame of mind - please don't shoot the piano player - write a better tune. 

I hope you are not offended by this advice from an old hack, but your issues really are very old in origin. Many experts have researched these issues and, today, a simple workable solution does not exist. To implement your choices you really need to rework the whole cycle of information engineering processes to allow the creation of reusable objects. If you can't do that (and who ever listens to writers on these subjects) then you should follow Arnis's advice and look at a different approach. 
Cheers 
Ian