After some thought i decided to contribute my 2cents. First, i think it is impossible to introduce a (re)initialization logic which would suit all different scenarios. Because it is really depends on what is stored in class variables and/or pools and if you add subclasses and then instances into the soup, you might end up with something which is really hard to safely reinitialize, because it may have some inconsistent state at different stages of initialization. It also, sometimes an order of initialization is important. What we missing, i think is a package pre/post load/update action(s) which tied directly to the package, so developer can decide by himself what needs to be (re)initialized and in what order without need of having some automated tool to decide it (often wrongly). I would really like that one day we could have packages as a first-class entities in a system, so we could express things in simple way: Package named: #Foo. Foo>> onLoad "perform an action when the package is first loaded into image" MyClass initialize. Foo>> onUpdate: oldVersion "perform an action when different version of package is loaded into image" MyClass reinitialize. of course, being able to control those actions is just a tip of the iceberg. P.S. i know that MC supports package pre/post load scripts (but strangely i cannot find where). so, it is really opaque to all of the tools, since it is outside of the source codebase of the package. P.P.S. Metacello also supports pre/post actions, so i think right now a best place where you can put (re)initialization code is into metacello configuration, and initialize things explicitly, rather than relying on implicit logic of tools. -- Best regards, Igor Stasenko.