I think a constructive module system would solve most of the current problems, and I believe this is what Ben and Don have in mind. Such systems, which I've used in PLT Scheme, specify the imports of modules as parameters that can be varied.
To take a simple example, consider a geometry package that relies upon a drawing package. Instead of hard-coding that linkage into the geometry package, that geometry package specifies that it imports certain functions (say, draw-circle, draw-line) but doesn't say where these functions come from. Only when the package is instantiated do the imports of the module have to be made concrete. So, for example, linking the geometry package to the drawing package creates a geometry package that draw on-screen. Linking the geometry package to the printer package creates a geometry package that draws to the printer. This is a simple and powerful system that doesn't involve state explicitly, but gives a lot of the benefit of 00 techniques.
Creating such a system can be done with classes. The module's imports become arguments to the constructor, and its exports are publicly visible functions (this requires first class functions, which TCL supports). I also believe this could be implemented with TCL's namespace, which are dynamic and may be a simpler solution than using [incr tcl].
