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