> Ignoring circular dependencies doesn't make them go away. Ignoring
> dependencies can lead to build failures that could have been avoided if
> they were expressed in a way that the dependency resolver could properly
> account for them.

++
One man's gawk is another man's KDE. A solution that expresses all
dependencies and handles them well is much more elegant than one that
requires hard-coding a list of core dependencies that we just think
are too complicated to work out.
Of course, to really get to the point where we'd have no system set at
all we'd need to somehow automate the dependency generation, since
otherwise ebuild maintenance would be very painful. Considering that
we can't even tell if a program will halt it is clearly impossible to
guarantee a perfect set of runtime dependencies. Of course, you might
be able to come up with something that is good enough - especially
when combined with the ability to add them in manually.
None of this completely solves the fundamental bootstrapping problem.
However, a full set of dependency specifications would let you at
least determine what the minimal bootstrap actually is.
I see all of this as more of an aspirational goal - one that we
shouldn't fret about not being able to achieve, or subject ourselves
to tremendous pain to get a little closer to. However, we also
shouldn't hold back when opportunities to take a step closer arise.
Rich