Change:
2.3. The application layer may be composed of several streams above FEC <del> and transport layers instances.  The different streams could exploit different paths between the sender and the receiver or not.  The document considers one application layer stream as input packets above a combination of FEC and transport layers.  In fig:multi-scope, each of stream 1 and stream 2 are considered in the scope of the document but a combination of stream 1 and stream 2 is not.  The case of multiple application level streams above multiple FEC and transport layers instances is out of the scope of the document and not further described. </del> <ins> and transport layers instances.  The transport layer may exploit a multipath mechanism.  The different streams could exploit different paths between the sender and the receiver or not.  This section describes what is in the scope of this document in regards with multi-streams applications and multipath transport protocols. The different combinations between multi-stream applications and multipath transport are the following: (1) one application layer stream as input packets above a combination of FEC and multipath (Mpath) transport layers (fig:multi-scope-single-stream), and (2) multiple application layer streams as input packets above a combination of FEC and multipath (Mpath) or single path (Spath) transport layers (fig:multi-scope-multi-stream).  In fig:multi-scope- single-stream, each of stream 1 and stream 2 are considered in the scope of the document.  In fig:multi-scope-multi-stream, the case with single path transport is considered in the scope of this document but the cases with mutipath transport is not.  The case of multiple application level streams above multiple transport layers instances is out of the scope of the document and not further described. </ins> 2.4.

Discussion:
I think this PR solves most of the issues that have been raised (and will close them if we merge this PR). What do you think NAME NAME NAME ?
I'm ok with whatever all others decide :)
In section 4.6: With coding, you can recover packets a-priori and a-posteriori, so I do not see any conjoint design between coding and the transport layer: if you replace the retransission mechanism by coding, you are more general as you can also recover packets a-priori and coding can offer full reliability if needed or partial reliability if the full reliability is not necessary. So I do not see any need of a conjoint design here: simply replace the retransmission-based reliability mechanism by the coding-based one. I do not really understand what we are trying to say here talking about a conjoint design. What do you think ?
I don't get it either... could we just remove this?
Commit URL in PR could solve it all.
It is a bit complicated for me to understand correctly the details of Figure 6 : In my opinion, the app does not sublit packets nor a sending rate to the transport layer, so the two arrows above the sender seem a bit weird for me. The app generally submits data, sometimes messages and maybe a minimal transmission rate but it is the transport layer that packetizes the data and sends packets. I guess that the arriws between the sender and the receiver are the wire or the layers below transport. Thus I would replace "source and/or repair packets" by "packets containing source and/or repair symbols" Did I misunderstand the Figure ?
I agree; I think the "sending rate" arrow can be removed (I'd say that the rate is at least implicit, in how fast the application gives data to the stack, but this just complicates matters - no need for this arrow anyway). I also think that "source packets" could just be "data" (next to the arrows on the top). This applies to figure 5 too ("source packets" can be replaced with "data" next to these arrows), and in figure 3, in the top left corner, the arrow could also be called "data" instead of "source packets".
There have been some changes due to the issue - I proposed a commit URL and commit URL in pr to clarify the unnecessary arrow.

In section 3, we can read the following: I would emphasize on en in-order delivery which is the real problem for FEC here, as a reliable messaging system without in-order delivery would work. I would thus replace the parenthesis by the following:
I agree but I'd use a different replacement: I think it's good to point out that this is about reliability from something different than coding, and the in-order issue is more than just a refinement in the bracket. So, I would suggest the following: a fully reliable in-order data transfer service (e.g., like TCP).
Dealt with in commit URL of PR
In section 2.4, we say the following: Either I misunderstood the statement or the sentence is not true. In my opinion, with an equal number of sent repair symbols, if the window/block size is larger, the recovery probability is lower as they are likely more lost source symbols in the window/blocks (with a fixed number of repair symbols).
Could be clarified by commit URL of PR
In section 2.4 : Why are we talking about a linear system here ? To be more general on the recovery algorithms that are used, maybe should we use the term "block or window" instead of "linear system" What do you think ?
The commit URL of PR makes it more general.
I am not totally sure of the meaning of section 2.3 and Figure 4. More specifically: are we saying that multiple data streams transiting through one single protocol instance are out of the scope of the document ? Do we consider only one single stream on one single protocol instance ? If this is the case, does that mean that we do not consider QUIC's use-case ? What makes me think all of this is the following sentence:
I hope PR and in particular commit URL clarifies everything
In section This is an echo from a previous issue that was not really addressed or "resolved". I will rephrase the problem from scratch and let me know if you agree with me or not. :-) We describe the FEC channel (maybe should we call it the Coding channel as repair symbols could also be sent a-posteriori) and say that it carries repair symbols while the CC channel carries source packets.

What do you think of rephrasing it like the following: "The CC channel carries network packets and the coding channel carries source symbols and repair symbols" ? source symbols are an abstract view on the application (and sometimes control) data that we want to protect. For example, several source symbols could be present in a single network packet, or several network packets could form one single source symbol. This is why network packets can be very different than source symbols. This also goes in our vision that CC and NC are separated channels and separated entities: they do not even share the concept of packets. What do you think ?
I agree there was some confusion here. I tried to solve this in commit URL of PR
Thank you for this great PR. Only one comment, otherwise this is good for me !