One of the interesting possibilities that dynamic scoping might present
is that it could be used to set a "behavioral context."  Currently
Squeak has only one global "behavioral context"...which is to say that
all objects exhibit the same behavior (roughly speaking) under all
runtime situations in which any given may find itself.

With some modification to the message binding algorithm and the
structure of object memory, I think you could construct a system where
objects could exhibit different behaviors when being utilized in
different runtime "behavioral contexts."

Every object would have some behavior that it exhibits in the global
(default) behavioral context.  Additionally, you could add behavior (and
corresponding state) that an object would only exhibit when it is being
utilized from within a specific runtime behavioral context.

A real world analogy is that people, when in different contexts, often
exhibit different behavior.

A good example is a domain object that exhibits GUI rendering behavior
when utilized in the "Morphic" behavioral context.  Upon first
utilization in the Morphic context, the object would adopt the rendering
behavior and state that you had previously defined for all objects of
its class.  This would eliminate the need to have two separate objects
for the model and the view, yet still have all of the benefits of
model-view separation.  Furthermore, if you had different morphic
applications for which different renderings were required for the same
domain object, each application could define its own behavioral context
(which would each inherit from the Morphic context).  Method lookup
would first look for methods in the specific behavioral context, and
then follow an inheritance chain of behavioral contexts, with the global
default behavioral context being the root of this heirarchy.

- Stephen