In the words of Arnaud (commenter on the blog), isn't the GateIn 
approach what you want ?

1 project with submodules, all have the same version thus the parent is 
the reactor ?
    

Different discussions.  The "GateIn approach" is *functionally* no
different than what we have today Max.  The only difference at all is
that our aggregator (the top level) does not (1) define the "parent
information" nor (2) inherit the same "parent information".  And as
Arnaud goes on to admit, the fact that Maven does not differentiate
types of metadata is a design flaw.
  

btw. I remember we initially did this parent were put in a dir on its 
own to make eclipse
happy - that is not really a concern anymore since later eclipse 
versions can handle
having a root project and just exclude the directories that are also 
projects in Eclipse terminology.
    

That's not the reason, no.  I split parent out because of 2 reasons:
1) (philosophical) because that's what makes sense
2) (practical) because otherwise you ended up having to run install on
root immediately after checkout to actually work on any of the
sub-modules.  As it stands today, you can install parent/ and then
immediately do your work on core/ because parent is the only piece it
depends on.  If "parent information" is merged into the aggregator you
instead have to run a full install (code, docs, tutorials, etc) just to
work on a patch to core.

Actualy #2 really illustrates why I find Maven's binary-only
dependencies cumbersome.  Binary-only is just another way to say that
the modules are separately versionable.  If Maven allowed source-level
dependencies (aka, these modules are always checked out and worked on
together and therefore no need to look in repo) then one would not need
to run the install on root initially to be able to do work on
sub-modules.  And the new -am/-amd stuff is a step in that direction but
its band-aids on top of (imo) bad design decisions.