Hi Florin,

I think I understand what you're getting at now. You prefer the "last 
package loaded" strategy because it guarantees that at least one 
package will remain in exactly the intended state, and thus presumably 
work. Ok, fair enough. I think this argument is moot any way since:

- What's appropriate probably depends on the circumstances under which 
we're running. If I as a developer am loading a handful of packages to 
continue development, I don't mind risking a little breakage. But 
that's probably not the case if we're deploying for end users.

- The modules system shouldn't be dependent on any versioning tool, so 
we may want overrides (or some other strategy for dealing with 
multiply-defined methods) as a fall-back for when the versioning system 
isn't present.

- Given Dan's interest in security, we'll probably want some mechanism 
for preventing such method collisions from occurring at all. 
Classboxes, Islands or E probably has some solution that is more 
elegant than either overrides or versioning.

> Part of a "project" may mean reverting a method to an existing,  older 
> version, reverting a class to an older version, reverting a package to 
> an older version. This happens quite frequently when developing a 
> patch. What does it mean for these components' history that you 
> re-version them?

In MC2, if a developer reverts to an older version, the history will 
show that. A new version will be created, with identical "content" to 
the old version, but with metadata showing the intermediate version as 
an ancestor.

Colin