When a user has multiple perspectives active it is possible, although probably unlikely, that those perspectives could have conflicting definitions. Actually, a single perspective may need a level of conflict resolution if it wants different behavior based on filter resolution.
The golden rule in this proposal is that perspectives are additive. Meaning, the user experience should encompass the union of the active perspectives. The goal being to enure the user can perform all available tasks, and access all available views. Put another way, the user should not in general need to:
be aware of perspectives
toggle perspectives to change view
guess at "what changed" in his view
It's actually not relevant whether this happens replacing a core UI extension point (i.e. existing menu item, tab etc) or adding a similar named extension.
The proposal is that each of the extension points is presented. We will need to work with UXD to decide how to present this to the user in a reasonable way. For example, two "Summary" tabs could be confusing, somehow they would probably need to be distinguished. (Summary-1, Summary-2 ?). Perhaps when replacing an existing extension point the perspective must supply an alternate name.
This is expected to be rare, so the resolution may not be hugely elegant. But it is believed that it is much better than forcing the user to know about and then toggle perspectives.
If in fact multiple perspectives want to take over the GUI start page we'll probably need to let them toggle the perspectives. The idea then is to present tabs at the very top of the GUI allowing perspective switching by name. An alternative would be to prompt the user which "View" they want to enter for this session and go there. Logout would then allow re-entry. Perhaps the logout dropdown could allow for a view change.
This is similar but what we end up with is the need for a Global "Default" view. Basically, a way to get to the extended core UI. The conflict resolution would be similar, but if a global view is not chosen the user would proceed to the default.
For example, one perspective removes the Summary tab and another adds Summary->mySubTab. In this case the "additive" nature of perspectives controls the behavior. The result is a Summary tab with one subtab, mySubTab. So, removals happen and then additions.
Note, additions can only take place if the "parent" UI component is navigable. In the above example, if for example the entire Resource UI component was replaced by one perspective (note, this may not be a realistic example, not sure that that is possible) then the mySubTab addition is invalid, as it has no context. Put another way, removals start at the highest level, which may make other removals and additions invalid.
This is probably a corner case with low priority but to document: If, probably based on the user's permissions, a perspective wants an extension point to link to different urls, then exclusive-or logic is required. The perspective definition would need to support this in some way.
Although maybe not a true conflict a related scenario follows. If perspective code calls back into an RHQ url, RHQ should apply any relevant perspective extension points.