I actually don't understand the term 'context' in this regard. I can only guess that you are referring to the problem that @ApplicationScoped might be underspecified. There is currently an open CID issue
Please note that CDI-18 is also related to this issue. The currently specified BDA ('Bean Archive') behaviour is not usable at all and even JBoss, Glassfish and WebLogic do not implement it as strict as the spec states (1 JAR == 1 BDA) but relaxed the restrictions a bit (but different on each server). I'm sure I don't need to say that this is seriously broken ...
So far my (long) discussions with Pete seems to come to the following conclusion (discussions not yet finished): We need to think hard about re-introducing the 'hierarchic' BeanManager as it has been in the Spec shortly before the spec got finished.
The BeanManager hierarchy setup would depend on the situation in the container, most likely 1:1 with the ClassLoader Hierarchy.
Means 1 BeanManager for the EAR would scan all the shared ear/lib ejb-jar.xml JAR files. Each WebApp would additionally get it's own BeanManager which would only manage it's own Bean<T> and delegates to the shared Ear-BeanManager.
This is needed due to how each javax.enterprise.context.spi.Context works internally. Each Context (e.g. a Context for @EnterpriseApplicationScoped) has a Map<Contextual<T>, T> and Map<Contextual<T>, CreationalContext<T>>. Thus for storing @EntrepriseApplicationScoped contextual instances, the Bean<T> (note: Bean<T> extends Contextual<T>) must be equal for each webapp.
This is a pretty complicated area and neither JBoss nor Oracle managed to do this right yet...