>> If I'm asking why a class should belong in two PackageInfos it's only
>> fair I answer why it shouldn't:  Because by the PackageInfo domain
>> model mirroring MC's model, they are able to work together better.
>> For example, the use-case I cited previously was one-click building
>> .sar packages (MaSarPackage on SqueakMap).  Utilities like that are
>> much easier to build and maintain when the cardinalities between the
>> models match.
>
> A class can belong to more than one Monticello package too.

By "belong to" I assume you mean "defined in".  Even still, "could"
does mean "should".  Again, I ask for practical usage-scenarios where
this is helpful -- in fact, you might start with why is it /not
detrimental/?

The prior example about being detrimental was ignored -- If you have
package "Foo" and package "Foo-Bar" and make a change to a method in
Foo-Bar, you now have two dirty packages.  Which one are you gonna
save?  Which one are you gonna load?  They're stepping on each other
so what normal use-case is this?

My goal w.r.t. this issue is to have a simple, practical model useful
for connecting Monticello elements with their in-image counterparts.
What's yours?