Architectural Guidelines for Multipath TCP Development
draft-ietf-mptcp-architecture-05

5.6.  Connection Identification

   Legacy applications will not, however, have access to this identifier
   and in such cases a MPTCP connection will be identified by the
   5-tuple of the first TCP subflow.  It is out of the scope of this
   document, however, to define the behaviour of the MPTCP
   implementation if the first TCP subflow later fails.  If there are
   MPTCP-unaware applications that make assumptions about continued
   existence of the initial address pair, their behaviour could be
   disrupted by carrying on regardless.  It is expected that this is a
   very small, possibly negligible, set of applications, however.  In
   the case of applications that have used an existing API call to bind
   to a specific address or interface, the MPTCP extension MUST NOT be
   used, since the applications are indicating a clear choice of path to
   use and thus will have expectations of behaviour that must be
   maintained, in order to adhere to the application compatibility
   goals.

I am not convinced your use of MUST NOT is correct here. In fact, it seems that it is in direct conflict with the following paragraph:

   Since the requirements of applications are not clear at this stage,
   however, it is as yet unconfirmed what the best behaviour is.  It
   will be an implementation-specific solution, however, and as such the
   behaviour is expected to be chosen by implementors once more research
   has been undertaken to determine its impact.

I.e., it is actually possible to know from the current socket API what is the application intent in this case?

I support David's COMMENT

This is a useful document.

I believe that it would useful to the community to note much earlier, and with greater clarity, in the document that it is applicable to the ECMP case.  Whilst few hosts are dual attached most networks have ECMP, and better ECMP is the subject of work in the Routing area.