A good set of reasonable questions.
> Can you explain why?  
I can try.
> Consider the following (please grant me the first point, in the
> interest of a meaningful discussion):
>
> 1) the community apparently supports the new contribution process,
> which is based on Monticello
All significant development happens in Monticello. However the
difference between most projects and this process is that most projects
have a title, and a defined scope, they have a plan, goals and they are
delivered in a loadable form.

If you were to propose "We are going to develop a better X" where X is
HTTPClient, then fantastic, go ahead.  I am quite happy for someone to
take on a subsection and go and make a better one.

But this isnt that. This is... we are going to develop a better X,Y, Z,
A, B, C, all overlapping, incremental, don't break anything way, come on
in, its all in one repository, do what you like, oh and btw This is now
a new branch of squeak, so we can do whatever we like without thinking
in advance about it. If you improve something its for us in our branch
that's what we want, after all we are moving forward and that is the
most important thing right?
> 2) the old process provided significant barriers to contribution (in
> the form of confusion, extra hassles, etc.)
The old old process had a significant barrier to contribution. That
barrier was "the release team". This process has a barrier too, its call
the "release team a la Andreas". Conceptually nothing has changed.

Those currently dwelling in other forks are getting nothing out of the
process, thus the audience for this process is the minimum part of the
existing community.
> 3) having an "update" button built into the default Squeak image is
> more convenient than having to first load Monticello
The "update" model is a push model. The update button pushes whatever
someone else thinks you need into your image. That new something has to
be incremental, it cant be revolutionary, it cant be refined over time,
it has to work.

My model is a pull model. You pull what you want, bob pulls what some
think would make a great release, those in forks can pull what they feel
would best contribute to their goals, and those things get planned,
implemented and refined over time. Those things can be small fixes or
revolutionary things like new gui's.
> 4) if there is a demand for lean, Monticello-less images, then Bob can
> easily build them
>
> You seem to take it as a philosophical necessity (axiomatic) that MC
> must be external, when in reality the question is one of pragmatics. 
Your "pragmatics" leads to every version of squeak having different
tools, and no way of updating them to what is current. Your pragmatics
leads to 4 different diverging forks of the MC tool set. Your pragmatics
leads to versions of squeak being released with significant parts of MC
tools not even working correctly (3.10 Monticello Configurations)

My pragmatics results in 3.7-lpf 3.8-lpf 3.9-lpf croquet-lpf Pharo-lpf
3.1.2-lpf and 3.11 all having the latest MC tools all of the time.
> Borrowing Edgar's "Devil's Advocate" hat for a second... why does
> Squeak-3.10 come with the Network package installed?  Surely this can
> be loaded manually by anybody that wants it, right? 
Yes, why indeed, and this has been done with the Kernel Image.
> The answer is that the convenience outweighs any the negatives for the
> Squeak community as a whole.  Someone running embedded Squeak on a
> submarine-robot might have to strip out the network code to make it
> fit, but nevertheless the network code "belongs" in the base image
> simply because of the result of this cost-benefit analysis.
But if the Network code is unloadable and replacable, then it doesnt
matter if you release an image with it or without it. If you want it it
is there, if you don't it is unloadable and replacable.

If you think about the problem in terms of modularity, then we can move
forward. If you think about things in terms of an image that someone
owns, then you lock people in.
> If Monticello is the way that the development trunk is maintained,
> then I want it in the same image.  To keep it outside is to generate
> unnecessary friction in the process, both to contributors and to those
> who want to simply want to keep up-to-date.
Its got nothing to do with whether a release image has it loaded or not.
It has to do with how you treat it, and maintain it.

Keeping MC outside the image, means that MC is developed and maintained
as a service to the whole squeak community, by a benevolent (and
hopefully appreciated) team working for the good of everyone. This then
means that the MC team has the freedom to implement new features, like
atomic loading and binary packages for the good of all.

Maintaining it as part of a release image limits it to serving the users
of a not yet released image only, which represents the minimum of MC
users out there.

Keith