Brian,

> I see SM as a system containing Community contributed 
> software, where the individual maintainers post new updates
> to those discrete packages, and I as a user can choose
> whether to update a particular package or not. 

Yes. And wouldn't it be appropriate to have the same ability when you want
to update your system to the next version?

> I see the update stream as dealing with "Core" Squeak code, 
> bug fixes, enhancements, etc, as fundamentally different the SM

Fundamentally different? Where? Both are mechanisms for distributing code
and whether a package contains a self-contained set of changes or not is
really up to the maintainer. For example, SmaCC requires the RB parse nodes,
Jacaranda requires Connectors. Where's the difference?

> I understand this line of reasoning, but I think this will 
> lead to confusion on the part of users, especially new users...

Most of the confusion of new users come from obscure UIs...

> and when the dependency code is part of the mainstream SM,
> and I want to load Jacaranda, then it will load 
> Ned's connectors and possibly.... say, bug fixes to Squeak, 
> so it revs it 3.5.3 or something?

If you're okay with pulling in Connectors why is it so problematic to you to
pull in a version update? In both cases you get "more than you want" and I
would claim that in both cases you should therefore get an information about
what is going on. For example:

Jacaranda vX.Y requires the following packages to be present:
	* Connector (vX.Y)
	* SqueakUpdate (vX.Y)
Do you want to load these?

The system tells you what it is going to do and it's at your disposal to
take it or leave it. To me, that's clearly an advantage about not being able
to load Jacaranda at all, don't you think?

> I would like to see (at least I think I would at this 
> point).. putting *all* bugfix type updated into the
> update stream... so if Magma has a bugfix posted 
> to it, when I choose "Get code updates" from the World menu, 
> it not only fixes my core Squeak bugs, but any installed
> packages I have as well (but not upgrading packages to new
> versions!)

But that's entirely unrelated to what I was saying. One is the issue of
hosting Squeak version updates at SquakMap (which I was talking about) and
the other is the ability to have update streams for each package (what you
are talking about).

Cheers,
  - Andreas