I know ENVY only from VA Smalltalk, and I can tell you confidently that compared to MC it sucks.
Cees can you explain me why it sucks. I'm new to MC.
I use ENVY to work every day. We use ENVY in a very particular way (we do collective code ownership and continuous integration, so we don't use all those "owner/manager" things, we don't use subapps or configuration expressions... and we use some in-house tools to handle dependencies and merging, if you want I can tell you more details -- I don't want to write a big boring mail--).
In my little experience with MC, I miss some things of ENVY (again maybe because I'm new to MC, and I use squeak in my spare time), those things are (in order of importance):
1. The lack of a reified concept of "application". I know that in Squeak are "categories", but they are only strings. Maybe an example can explain this point: In our system we use GemStone. We try to make that our app portable between VAST and GS (this makes our lives more easy because debugging and developing directly in GS is a pain in the ass). So we had extended the applications to respond to the message #gemStoneSynchronizer. So all applications are polymorphic to this message. Each time that we want to upload the code to GS, an object simply iterates over all applications in dependency order (using a topological sort) get its "synchronizer" and executes it. The synchronization depends on the synchronizer implementation returned by the application (some applications are not uploaded to GS, some uploads a GS specific implementation, by default all applications returns a "null" synchronizer that does nothing). This would be more difficult in Squeak , because you have to do an object that maps the category String with the specific synchronizer (for example I dint found a way to use a particular instance to MCPackage that depends on the application... oh well category).
2. Is there a way to do something similar to "configuration maps" in MC? (or Bundles is VW)
3. In ENVY each time that I save a method a version of it is created on the repository. In MC I can revert the changes on a method but I didn't found a similar functionality.
4. The "Make image consistent" is really useful when you have an image crash (I know in the end you have to check the doit.log like in Squeak to ensure that everything is back again, but I found that this in ENVY is much more easy: simply "Make image consistent" load or discard different methods, and then check that there is no Undefined classes in the image --this test is easy to do because the application object responds to #undefined with the classes that are missing)
5. I really miss the three way diff :) (we have done an special version that shows with colors those methods that can be merged without conflicts: the ancestor and the current version are the same)