I'm not sure I follow; are you saying that we should collapse the reactor phases into the main project build lifecycle as a new version of the existing default, and then selectively execute part of that lifecycle outside the reactor, and other parts within the reactor (i.e. per-project)?
The reason I like the concept of scoped lifecycles is that any existing project today, when released, may have a need to produce a binary assembly that contains all of the module projects, etc. If we wrap the existing (or any other) lifecycle inside a reactor-level lifecycle, then these people will have the ability to bind the assembly plugin outside of the project-level lifecycle and have it execute at the appropriate time.
IMO, the semantics of binding to a project-level lifecycle (for war, ear, ejb, etc. packaging) shouldn't change in most cases with this addition.
However, now that I think a little more about your use cases (eclipse plugin dev), I think I see what you're getting at. You'd like to be able to specify something akin to <packaging>war</packaging> and have the reactor-level lifecycle bindings be provided by the default mapping for the packaging.
We already have three lifecycles used in Maven, and a given packaging can choose to override any of the three. They are: clean, site, and default. The default one is for "normal" builds, and the other two are pretty self-explanatory, I guess. What if we added another lifecycle called "reactor" or "multimodule" which would allow mapping of things like your pde pre-processor mojo when the packaging == pde-plugin or similar?
If you want to see how these are constructed, have a look at:
and search for 'DefaultLifecycleMapping' to see how the different packaging types are mapped in.
Would this meet your requirements?