Yes, we definitely agree on not "adding broadly-scoped functionality". Where actually what i did, was likely the easiest/quickest way to implement what i wanted it to do - maybe i just shoudn't have attached that prototype though ;)
As for the actual deployment processors - "just a simple transformation of data or mapping from data to built services, with all the logic being in the actual service" - is certainly all the deployers should do (beside setting up the deployment classloader). When mentioning common EE injection in the deployers i was referring to the resolution of @Ejb -> service dependency name, since this would be needed to create the proper service dependencies. So maybe the deployment framework should also define a formal contract for this kind of resolution? The actual injection would be part of the service lifecycle