How many states on each end?

Technically, one consequence of the differing view of whether the
exchange completed successfully is that the receiver may remain in the
"init" state regardless of which state the sender goes to.  E.g.,

    * I send a UDP packet, the receiver's gateway is down.  I transition
      to success, the receiver hears nothing and stays in init.
    * I try to send a UDP packet, but my gateway is down.  I get a no
      route to destination error and go to failure.  Naturally, the
      receiver hears nothing.

There may be a subtlety here.  The sender knows when it's going to try
to send a message.  We could model this by making "init" an "idle" state
and transitioning to "sending" when actually trying to send a message. 
The receiver, on the other hand, doesn't know anything's happening until
it actually starts to happen, so its "init" state is more like
"listening".  Once a message starts coming in, it either comes in or it
fails to, but we could insert "receiving" analogously to model the
receiver becoming aware that something is coming in.

Whatever subtlety there is here is also present in the request-response
MEP, and the request-response MEP does indeed include intermediate
states; Init is different from sending on the request side and receiving
on the response side.  This distinguishes "I'm idle" from "I'm sending a
request" and "I'm waiting for a request" from "a request is now coming
in."  It's a bit confusing that the Init -> Sending condition is given
as "unconditional" as opposed to "Start sending request message," but
the distinction is still there.

The question is, who wants to know this distinction?  From the point of
view of determining whether the MEP succeeded, or whether anything
happened at all, three states on each end are enough.  In practice,
there will always be some sort of timeout ensuring that one does not
stay in the "sending" or "receiving" state indefinitely, and regardless,
we don't want to make a pronouncement while still in those states.  In
other words, if I get to "receiving" I will always go to either
"success" or "failure" and if I don't, I simply stay in "init" as
described above.

The intermediate states only seem useful if external entities want to
query whether anything is in progress, or conversely if the node wants
to notify them on transition, but how finely do we want to slice this? 
We could easily add "envelope built" or "headers processed" or whatever
and argue for each of them.  I could particularly see an argument for
"headers processed" in the context of WSA and fault handling.  However,
I would prefer to keep the MEP definition minimal and layer finer
distinctions on top of it.  We can always define, say, "receiving" and
"headers processed" later and define them as equivalent to "init" for
purposes of determining overall success and failure.

Normally I'd tend toward the "request-response is that way for a reason"
school of thought, but while that's almost certainly true, I've seen
(and done) enough pushback against the request-response state machines
to want to re-examine them.