Item 3 is when bandwidth available to a specific flow in a intermediate uplink is limited. This occurs even if you have a 1 TB/s intermediate link as long as there are 1000 1 GB/s flows (of potentially heterogeneous origin) that go through that link.

Unless every intermediate link has more bandwidth than the sum of every flow that goes through it, you have this problem. Thinking about that more, that is literally just “congestion is possible”. But if congestion is not possible, then there is no bandwidth limiting and you can just blast away at full speed at all times.

I guess I would characterize this as congestion control/bandwidth limiting where your control parameter is “in-flight data allowed”, which is what TCP also does, results in exactly that. You get intermediate buffering due to no pacing mechanism unless you are giving rapid, continuous, precise congestion control feedback. The control parameter that avoids that is available bandwidth (or estimated available if you are not omniscient) which allows the Tx to interpolate between explicit congestion control feedback. This allows reduction in rapidity of congestion control feedback while neither stalling nor over-producing. You just tradeoff responsiveness to channel parameter changes in proportion to how rapidly you provide explicit congestion control feedback.

Data flow prioritization within your available bandwidth is, however, still necessary and largely orthogonal to the above.