While Xtext is a powerful tool, it is sometimes easy to loose the big picture of the linking, scoping, global scope etc. For my own mental relief, I have made a little diagram, which might be useful for others (no guarantee for correctness or level of detail). It applies only to a specific configuration (using Xbase and Imported Namespace Aware Scoping).

So basically what happens is:

1. Parsing: The framework parses the model files (Xtext-files). Links between elements are not resolved yet.
2. Index Building: The model is traversed, and basically everything reachable that has a name attribute is packed into an EObjectDescription and that is put into an index. What is put there can be customized. Caveat: EObjectDescription allows you to have some user data stored with your description in the index. Often the first thought is, to store e.g. some type information or, e.g. in case of class models, some inheritance information. However, references are not yet set up / linked. So you cannot put anything in the user data that would traverse link references!
3. Lazy Linking / Scoping: This is where the actual linking is done. In our case (Xbase-based language), this scoping is based on XbaseScopeProvider. This actually delegates to some Guice-configured class, which in our case is an ImportedNamespaceAwareLocalScopeProvider. This looks for model elements with the attribute “importedNamespace” in your model and pulls the objects from the index, that match any of the importedNamespace values (you can specify wildcards in the imports).
   In addition, in these classes you can add your own scopes, the local scopes, which are derived from the existing model information.
4. Content assist: Uses the scoping data for suggesting alternatives.

The index is transient in memory and is loaded from / stored to disk on start / stop of Eclipse. During run-time there is no up-to-date representation on disk. The org.eclipse.xtext.ui.shared.Access class can be used as a handle to index data.