Yes, and we might want another mini-pkgsrc with just essentials, and one
   with commodity stuff, and ... 

So I guess your question is, where to draw the line?  I agree, we
clearly don't want lots of random pkgsrc subsets.  People can
certainly select customized subsets of binary packages from the web
site or can compile/install customize subsets from within an
up-to-date pkgsrc in its entirety.

However, as I see it, there is a fundamental difference between
subsets of packages that are useful in certain applications but not
others, and ONE subset of pkgsrc that MUST be up-to-date to install
ANY other binary packages.  The mk/pkg_tools subset is the latter not
the former.  As has been mentioned already by someone else, it is
essentially a component of the system that needs frequent updates, not
a typical subset of pkgsrc.  As such it would seem to fall into a
category all by itself and perhaps warrants a special case
distributional method.  This by no means implies that we should
consider other random subsets, because of the problems (I think) you
are concerned with.

So I see a very clear line that distinguishes the nature of the
mk/pkg_tools subset from any other subset of pkgsrc, and don't foresee
the endless expansion you seem to fear (and agree that we should avoid
that).

Cheers,
Brook