Hi Dave,
I would try it with wrapped traces instead of cloned traces.
If I understand correctly, your trace has two call stack analyses. Are they using different output files for the state system? If they are using the same file it might explain some of the problems.
In your overloaded CallStackView.getTracesToBuild(), create a new list and for each trace returned by the super.getTracesToBuild() (in case of an experiment with multiple traces), if it is one of your traces create two wrappers around the original trace, and add them to the list of traces to build.
The wrappers could just be a subclass of TmfTrace that have the original trace as a private field, and another field to indicate which analysis it should use.
Override getName() to append something (the selected analysis number?) to the original trace name (so you can use that in your filtering content provider).
Override getAnalysisModules() so that it returns only the call stack analysis from the original trace that corresponds to the selected analysis.
Override getFunctionName() so that it returns whatever the original trace returns.
I think you can return anything for all the other abstract methods that need to be implemented, I don't think the call stack view (the only object that has visibility to those wrappers) will call anything else on them.
Patrick