Hey David,
I too think that CDI is a core technology that is vital to get right for EE4J and a good test of the process and collaboration.
Historically it has been a difficult one because it clashes with other specifications on definitions of specific annotations and the implementation of scanning for annotations.
Previously, it has been very difficult to avoid multiple annotation scans being done, by container, by CDI, by other JSP, etc. etc. Now with java9 MR jars and modules as well as classpaths, it is even less clear what jars should be scanned and what classes within those jars should be visited. It is a real disappointment that java9 didn't provide some good common annotation scanning support, specially as so much more of the jars / classpath / modules are now hidden.
So for various specification to play nice with each other, we really need to cooperate on object creation and decoration in a way that facilitates legacy annotations, full CDI support and perhaps what ever might replace CDI (as picking winners is seldom good).
From the servlet spec point of view, I would resist any "you must support CDI" initiative, but would embrace a "please open up and standardise your object creation and decoration"
Note also that I would love to see some standard for features to be able to persist and replay the results of annotation scanning. In a micro service virtualised deployment it can be dire to ask a user to wait 30 plus seconds when spinning up a new instance to allow annotation scanning to take place over jars you know have not changed, but that you don't know what the features are looking for in them.
cheers
