Wow, my crazy little idea generated quite a bit of discussion.  The  
funny thing is that I didn't really consider the 'dot' part all that  
crazy, in fact it is actually not new to Smalltalk.  GemStone uses  
it, and my post was actually triggered when I found out that ThingLab  
uses it to enable change management.

My central idea was that messaging consists of naming the  
participants and then sending the messages, and that naming is really  
just a special case of selection (compare 'Design Principles Behind  
Smalltalk').  Generalizing naming to selection by allowing 'complex  
names' would not really be a change to Smalltalk, but more the  
lifting of a current restriction on what can be accessed by name.   
The idea is definitely not just to provide convenient shortcuts for  
certain message sends, although that is a nice effect.

See 'Adaptive Programming' (http://www.ccs.neu.edu/research/demeter)  
for a more thorough treatment of the problems of graph traversal and  
an interesting solution.  Having a name for 'the contents of this  
collection' or other dynamic entities is something that appeals  
greatly to me, especially if the mechanism is simple and can be the  
core for quite a few other applications.

However, this is really a blue-plane idea, and definitely something  
that needs to be thought about a little more, although as Stefan  
demonstrated, a simple version isn't really that hard to add.  A more  
comprehensive approach that also takes name-spaces into account  
would be to treat (complex) names as entities that are resolved  
recursively in the dynamic execution context, with only simple +  
local names being resolved at compile time.

Marcel