reverse of out-(in|ifault)*

This is a follow-up on the out-(in|ifault)* pattern (i.e. a multicast 
output message followed by input/fault messages from different nodes) 
discussion.
There was some discussion about its related reverse pattern.
If I remember correctly, the reverse chosen pattern was in-(out|ofault) 
which is also the reverse of the out-(in|ifault).
I would argue that the reverse pattern might in fact probably be 
in-(out|ofault)? because a multicasted receiving node might not even 
want to answer to the incoming multicasted message.
The desired number of interaction patterns to describe would grow from 7 
to 8.
in
out
in-(out|ofault)
out-(in|ifault)
in-out*-ofault?
out-in*-ifault?
out-(in|ifault)*
in-(out|ofault)?

Following the "soapish" mep approach (where nodes are defined but the 
service is not identified), we would need to write 4 specs.
Following the "non-soapish" mep approach (where the service is 
identified in the spec), we would need to write 8 specs.
Interestingly, it seems that the out-(in|ifault)* pattern is not 
entirely defined if we do not define its reverse pattern: the pattern 
out-(in|ifault)* is very different whether all receiving nodes must or 
may answer (i.e. whether its reverse mep is in-(out|ofault) or 
in-(out|ofault)?)

What is interesting with the "soapish" mep approach is that you do not 
need to care about the reverse patterns, they are already in the 'not 
reversed' specs  :-) . And because they are already defined somewhere, 
we do not need to define by their own  ;-)

    Youenn