I don't know, if you ever have read my workflow-ng proposal, which has some similiar things in. -> http://more.zites.net/node/3030 I've also posted it to the workflow group.
Actually I've planned a layer between actions and hooks: events. It should achieve, what you have built now as contexts. Events sit on top of hooks and prepare the context for use with actions (and conditions..).
Yes, I've read your proposal. It sounds a lot like something Vlado proposed a while back; essentially a layer of abstraction above our current hook system. Although I am drawn towards greater and greater abstraction, I think currently the best approach is to treat the current hooks themselves as events. They already occur in predictable contexts and pass predictable parameters. Modules are welcome to define their own hooks.
E.g. some of your default actions load the $node for the context comment. Ideally that could be factored out of actions, so that a code reacts on comment insertion/update, prepares the data and calls the event, which fires configured actions / conditions. What do you think about that?
I think that as long as we have types of actions, we can factor it out. For example, you know an action of type "Node" such as "Promote node to front page" is going to need a node to act upon. Thus, you can factor out the process that goes "Hey, this action is being called during the comment-insert hook/op combination and the node is not available; thus, pack the node into the context during the action.module's implementation of the comment hook." However, you have to be very careful about this. The action itself knows the most about what it needs, and we want to avoid stuffing everything and the kitchen sink into the context just in case the action needs it.
The next major hurdle for actions consists of action sets and conditionals. Action sets are groups of actions that go together. Conditionals evaluate and determine whether an action set actually executes. eaton has paved the way for both of these in his voting actions module. Unless we're very busy bees, that will have to wait for Drupal 7.
My concept also builds upons conditions. Perhaps I can help, so that we could already get it into drupal 6 :)
If you are interested in my help on this - Where can I reach you for talking about this stuff?
I've created a group at http://groups.drupal.org/actions for such discussions.