I'm having trouble understanding what everyone is criticizing here.
Is it that PackageInfo does not keep its own state?  That it relies on
the category names of classes and methods to know what is "contained"
in it?

Or is it a criticism of the notion of having a delineation of
classes+methods at all that make up a single executable "program"?

You all are smarter than I, I'm just trying to learn..

> PackageInfo is an awful fake. It not much better than a dummy state holder,
> while various parts of system (including MC) trying to play with it.
>
> It would be much nicer at some day to have a proper reification of
> packages in system, so they
> could be in charge what goes inside them, and what are relationships
> between them.
>
> I dreaming that some day we could do stuff like:
>
> newClass := Object subclass: #Foo.
>
> myPackage add: newClass.
> myPackage add: (Object>>#extensionMethod)

Wouldn't that be a separate step though?  Right now, we kill two birds
with one stone:  categorizing classes and methods, AND assigning their
Package at the same time.  Wouldn't separating these two activities
lead to extra work and ambiguity about what code is in what
package(s)?

> and even:
>
> myPackage add: icon.
>
> and then:
>
> myPackage serializeTo: aStream.
>
> and then:
>
> myPackage := Package loadFrom: aStream.
>
> what could be more simpler and powerful?

As for the icon, with MaSarPackage, you can simply override
#resourceNames in your own PackageInfo subclass and it handles the
serialization of those files into the Smalltalk-Archive (SAR)
automatically.  Since that method is saved with the MC package, it
only needs to be done once.  Very simple.

>> There's no actual modularity going on with them, which is confusing to new people who've had modules in every other language that were namespaces.

I just don't understand this statement.  The modularity is that of a
set of code-elements that work together to solve a real-world
problem..

 - Chris