Some additional wording in protocol spec (2013-03-12) sections 10.4.2.2 and 10.4.2.3 might help to answer the following questions.
Some backend systems support creation of composite objects (e.g. a "purchase order") as a composite operation requiring parent (e.g. order header) and children (e.g. order lines) to be provided together. And also, they require additions, alterations, and deletions of children to be issued as composite operations against the parent (with either merge or replace semantics, we have seen both).
In other words, the POST request to create the parent would REQUIRE the related child entities to be included inline. And PATCH requests would need to support inline additions/updates/deletions of children.
Q1. Are such "composite" relationships expressible with CSDL (without the use of complex types for the children, but using entities for both parent and children)? If so, then how would that affect the wording of sections 10.4.2.2 and 10.4.2.3.. (One might stipulate that the use of OnDelete="Cascade" is one quite strong indication of a composite relationship).
Q2. Even if "composite" relationships are not expressible (except by using complex types for the children), another question may apply to section 10.4.2.3, is that whether a PATCH request is permitted to include inline values for navigation properties? (Can we "update" existing children of a parent without replacing all the parent's children, or must each child be separately updated).
Q3. Is there any support in CSDL/protocol for composite relationships (whether children use complex or entity types) that permits "merge" (rather than "replace") semantics for child objects?
Q4. Assuming that the answers to all the above are "No", is the server allowed to REQUIRE the use of a batch request (with a change set) when dealing with "merge"-style changes to composite relationships? (Perhaps not currently, but that might be a way forward if we were to consider a future extension).