• A root Parsley project that defines and initializes a resource containing an object with a cross-reference feature [1] to some other model in some other resource, which is managed by some other Parsley project. The root project defines its own view part (based on a SaveableTreeFormView), feature providers, and resource manager. This root project is generally ignorant of other Parsley projects.
  
• An arbitrary number of leaf Parsley projects that define their own view parts (also based on SaveableTreeFormViews), feature providers, and resource managers. They know about the root project and can obtain its injector.
  

• The root resource is generally updated via an outside mechanism. Via a UI runnable, the mechanism obtains the root injector, and then its editing domain via its subclassed AbstractSaveableView view part. The mechanism then obtains the command stack and adds commands to it.
  
• Leaf projects receive notifications of interest from the root project, possibly via an EContentAdapter or CommandStackListener). Via these notifications, a leaf project may create a composite command on its command stack: create a new object within the resource the leaf manages and cross-reference the notifier to this newly created object.
  

• Since transactional editing domains aren't in use by the root project, the root project is susceptible to dirty reads. (It could be reading whilst commands are being executed in the UI thread.) However, since it's running in the UI thread and using commands, writes should (?) be OK. As a work-around the reads could also occur in the UI thread.
  
• Since the root project is ignorant of the leaf projects, it'll also be ignorant to changes in the leaf projects resources (like saves, deletes, etc.). So it'll have to employ some mechanism, like unloading / reloading resources, before trying to resolve the cross-reference.
  

interface DomainDomain {

	refers DomainDomain source opposite destination
	refers DomainDomain destination opposite source
}

If I understand your scenario correctly, then as long as all the views use resources in the same resource set, then all notifications should be delivered correctly.

• Create an object in view1
  
• Create an object in view2
  
• Navigate back to view1 and undo
  
• Expected: the object created in view1 is undone
  
• Actual: the object created in view2 is undone
  

Using the same resource set is just a matter of using the same editing domain, which, in Parsley can be achieved at a JVM level (org.eclipse.emf.parsley.edit.domain.GlobalAdapterFactoryEditingDomainProvider) or at injector level (org.eclipse.emf.parsley.edit.domain.SingletonAdapterFactoryEditingDomainProvider).

the fact that a view changes its selection due to a change in an unrelated resource looks like a bug to me! Could you please file a bug and I'll try to fix it ASAP. We could even do a minor/bugfix release without problem.

the single stack per editing domain is instead a safe choice, at least that's what it looks like to me... two changes in different resources could be related (a reference to an object in another resource of the same resource set) and they should be undone consistently. Does it make sense?

• A user creates a new object in resource A via viewer A. Only resource A is affected; resources B and C are not affected.
  
• A user navigates to viewer B and executes a composite command that creates a new object in resource B with a cross-reference in resource C. Resources B and C are affected; resource A is not.
  
• A user navigates backs to viewer A.
  

If so, it seems like a single workspace transactional editing domain would mitigate or remedy the issues above, however with possibly the added complexity of integrating the Operation History API calls with the Parsley views and components, in addition to overriding the editing domain provider and editing domain finder.