As I look more, I begin to see a problem in my plan. It's in the last paragraph of the above, which assumes that we can figure out which of a set of multimethods will be called in any purticular circumstance very early -- it'd require evaluation of the RHS before we determine what context to evaluate the RHS in. It may be neccessary to provide the context of the RHS as an explicit attribute of the method, and disallow having different versions that vary by rvalue context with the same non-rvalue signature.

The order of evaluation would then go as follows:

1. Invocant.
2. LHS arguments
3. At this point, we determine which of the potentially competeing multimethods to call. If there are none, or more then one with the same goodness, error (possibly not error, but just pick the first or last in the second case).
4. Determine the context for the RHS.
5. Evalute the RHS.
6. Finally, call the actual lvalue method.

I realize that this makes reverting the value somewhat more complex from the core -- but if the core thinks of the rollback as being a new assignment, and propigates exceptions thrown, it shouldn't be much more difficult. (Note that this is hardly the only place that exceptions can be thrown from nonobvious places.) I think it's far more important to give an interface to lvalue subs that matches the way people think about them.