-If using a separate @McInject annotation instead of @Inject to do injection the annotated field does not appear in invocation context's injection points meaning all the fields etc. need to be parsed from invocation context's target's class (I am not sure if the target will always be non-null?)
It will always be non-null, otherwise we will be trying to inject into a null instance...
-It does not get triggered when calling constructors
Correct, but it is probably reasonable to extend it support this for Weld 1.1
-If using the @Inject annotation with an additional @Mc annotation (to look up the particular injection point in the MC) falls over when calling proceed(), also again a problem is that you need to iterate over all fields etc. to look for the members. This also fails in the validation pha
It is possible to overcome this, but I think it just points at underlying problems of this approach.
At the moment I'm pretty unconvinced about adding these extra SPIs because I remain unconvinced of the validity of this approach - essentially you are opening the door for introducing other resolution algorithms which aren't spec'd, which I don't see the value of for users.