"I often want to model ‘what if’ scenarios, i.e. what the various architecture domains would look like if we proceeded with Option A, or B etc ... [but] I don’t want my various different options to ‘bleed’ into each other in the model. ... The only way I’ve found round this in the past is to duplicate parts of my model to keep them separate (in different packages etc) - which is a bit ugly."
Of course, the problem Robin identifies is more than just time sequence dependencies. Sometimes we have to explore the differences between A-followed-by-B and B-followed-by-A, but there may be many other permutations to explore. If you have to duplicate parts of the model for each permutation, this severely limits the number of permutations you can compare.
Many architects will try to solve this kind of problem by abstraction - coming up with a model that abstracts away from the differences between the options, so that the model supports all the possible options and all the possible permutations between the options. However, the standard model isn't then much good for comparing the options. In some cases it may be worth building a flexible capability that can support both A and B, but how do I tell whether this is one of those cases?
(Michael Bell's SOMF modelling approach does allow AS-IS and TO-BE to be shown on a single diagram, but I don't know how practical it is to put multiple alternatives on a single diagram.)
What Robin highlights here is that the standard modelling tools and notations aren't always very helpful at supporting choice, especially when the choices get at all complex. Often it seems that the tools only really work for documenting the architectural and design choices that have already been made, rather than for making the choices in the first place.
The best answer I can give Robin is to use the available tools, but to adopt a different modelling style. But I need a good case study to work on. Contributions welcome ...