I tend to think of method calls as messages – I then also try to think of the thread as a queue. The messages are sent to the queue and executed. This makes code weaving the process of observing the queue and triggering actions when certain events happen on the queue. The action can alter, cancel, repeat or simply pass the message through.
I like that design very much – Swing for example uses the event queue for all it’s messages (even adding a component to the UI tree is a message). One can easily design an application to use a similar pattern – for example, if you create a queue and messages that change your model (messages would be commands) instead of a simple API to your model you can then handle things like undo/redo through the queue messages.
The Cairngorm framework for Flex makes use of messaging as well in order to make the client/server communication and interaction with the client side model and the server side model easier.
I feel using queues and messages makes it easier for other programmers to understand what is going on in the application (the queue is a much easier concept to grasp than the code weaving).