Constraints for multicast

Here is what I want to be able to capture about multicast.

    * Actual implementations do it.  If I publish a message, or send it
      to a mailing list, or send a broadcast or IP multicast packet,
      multicast will happen.
    * Multicast looks like a single operation to the sender.
    * Multicast looks like a single operation to /each/ receiver.
    * The sender and all receivers are participating in the same
      operation, particularly for the purposes of logging and error
      reporting.

I believe the approach I've proposed, of the binding specifying a
mapping from the address the sender gave to zero or more receivers,
handles this cleanly, both in that it's close to what actually happens
in implementations, and because it adds very little extra verbiage to
the spec.  The current text reflects this approach, though it doesn't
mention the mapping explicitly.

This approach is based on an ether model, which I believe captures what
happens in real life in a wide variety of instances:  The sender sends a
message into the ether.  Each receiver sees a message emerge from the
ether.  What happens up in the ether is its business.  In the olden
days, of course, we used to have black boxes to do this kind of thing,
but ether suggests something more widespread and diffuse.  In real life,
the ether could be the email infrastructure, with a mailing list handler
inside, or the network itself, or your favorite messaging
infrastructure, or a radio channel, or whatever.

Noah mentioned (at least to me), a model in which a single logical
destination is embodied as multiple physical destinations.  I think this
is very close to what I proposed, the main question being whether it can
be separated out from the one-way MEP description proper.  From the
sender's point of view, it definitely can.  The whole point of multicast
is that at least in normal operation it looks the same to the sender. 
What concerns me is the constraint that the receivers are all
participating in the same MEP.  In particular, the sender may get error
messages from multiple receivers for the same MEP (e.g., bounce messages
for multiple members of a mailing list).

Because the MEP looks like a single operation to the sender, I'm
skeptical of a multi-MEP solution.  AFAICT, the sender would be
participating in a composite operation consisting of 0 .. N MEPs, which
all look identical to it.  The zero case looks especially troublesome. 
Even if there's no one to hear it, the tree still falls.  Maybe I'm
missing something, but this seems like it would be a pain to word
precisely, and it doesn't seem particularly close to the ether model.