Original text:
6.3.2.  An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and

Reviewer comments:
They won't be wasted until we have 64 message types valid on unidirectional streams. We currently only have 3 valid messages types. I think you mean that we could save the message type byte if OBJECT is the only message allowed on unidirectional streams, but that's not forward-compatible.
Draft-02 strongly implies the forwarding preference is a per-object decision. thus the following sequences would be legal: [sequences are written as (group, object)] Stream 2: (0, 1), (0, 2) (0, 3) (0, 5) -- type is StreamHeaderGroup Stream 6: (0, 4) -- type is ObjectStream or Stream 2: (0, 0), (1, 0), (2, 0), (3, 0) -- type is StreamHeaderTrack Stream 6: (1,1) -- type is Object Stream etc. If someone can imagine a use case for this, that's great. If not, it would be easier to implement with different assumptions, e.g. (1) Forwarding preference is a track-level property. Thus the preference could be provided in the SUBSCRIBE_OK and we wouldn't evens strictly need four different object codepoints (though you would want the distinct formats, and might want to retain the codepoints for that reason) (2) Forwarding preference is group-level -- some groups could be aggregated under StreamHeaderTrack, but others could be under StreamHeaderGroup. If there is a StreamHeaderGroup for a group, there MUST NOT be object-level streams for that group. Again, I have little sense of the use cases out there, but I think we should explicitly decide what we are doing and make it clear in the doc.
A related question is whether forwarding preference applies across subscribes. That is, for per-group streams, a current subscriber gets all of group 12 and then the stream closes. a later subscribe in the same session asks for group 12. Obviously, this will need a new stream. So maybe the answer is no, it does not apply across subscribes
I agree, this is very difficult for a decoder to support. The target use-case is non-reference frames. In your first example, object 4 is optional so it gets its own stream. However the receiver doesn't know that, instead it just sees a gap between 3 and 5. Does the receiver try to decode and catch any errors? How long does it wait before trying? If I want minimal latency, do I have to partially decode (on a per codec basis) to get the frame dependency graph? I really don't like this option. I instead want an explicit way to know that this object is a non-reference frame. Ideas: Make a separate track for non-reference frames and SVC layers. Receive a formula that every 3x+1 object is optional? Receive a live object catalog containing metadata about each object. My vote is a separate track and each track has a uniform forwarding preference.
I like the idea of uniform forwrarding preference for a track. That's what I had in mind when we landed that PR. I can't think of any use cases this restriction prevents.
I think the consensus in Denver was to have one preference per track
just to be clear , the preference is set as track level property and can have 4 values - track, object, group and datagram.
Yes, although for various reasons the PR I'm doing is going to make it subscription-level property. I think is hard to write it otherwise, and I can just about see a use case for it.
When a few of us discussed it last week, the feeling was that if it came back in the SUBSCRIBEOK, and Objects started arriving before the SUBSCRIBEOK, the receiver wouldn't know how to process the incoming Objects. In the past, we've decided we don't like that, so the feeling was to land a PR to add the restriction now, and then we can talk more about wire format changes. NAME Is Object decoding not an issue for some reason I'm forgetting? Or were you thinking that buffering Objects was fine?
I am arguing that buffering objects is fine. The usual case, I think, is that SUBSCRIBE_OK arrives first. It's irritating we're using a byte in the object encoding (and creating new error conditions to check for) just to avoid buffering. But I can live with keeping it for now.
This is an improvement, though I would still like to get rid of all the wasted bits

Revised text:
6.3.2. <ins> Every Track has a single 'Object Forwarding Preference' and publishers MUST NOT mix different forwarding preferences within a single track.  If a subscriber receives different forwarding preferences for a track, it SHOULD close the session with an error of 'Protocol Violation'. </ins> An "OBJECT_STREAM" message carries a single object on a stream. There is no explicit length of the payload; it is determined by the end of the stream.  An "OBJECT_STREAM" message MUST be the first and