I'm not saying you can reuse the entire SSE protocol and interfaces, but why not use 200 and Content-type text/event-stream, like SSE does? Use mixed/subscription of mixed/braid if you really want, but this whole new thing, why?
I don't see what's too fundamentally different about Braid that it needs a new status code and protocol. Shouldn't SSE use 209 then?
It's possible that Braid could switch back to status code 200. I expect this choice to be revised in discussion within the IETF HTTP WG, but we haven't gotten to this level of detail yet. If I remember correctly, the switch to 209 in the current draft was to discourage middleboxes from caching braid responses, but it's possible that "Cache-Control: no-cache" does enough of this and that 209 is not necessary. I'll keep an eye out. Thanks for the thought.
As for text/event-stream -- braid responses are not text (they can contain binary updates to things like images) and they are not an "event" stream. Braid provides an "update" stream, as a stream of HTTP responses. Each response can specify an update using a status code, headers, and a body.
If we were to use SSE, we would be encoding an HTTP response, within a base64-encoding (to fit as text), within a sequence of `data: ` lines, in an "event", within an event stream, within a text/event-stream content-type, within an HTTP response. It's a lot simpler to just extend HTTP to say "instead of one response, a server can provide N responses" than to go through all this rigamorale to encode responses within an event stream within a response.
As for events vs. updates, an update may or may not describe the raw underlying events. Updates can also be summaries of many events. For instance, a normal HTTP response body provides a snapshot that summarizes all of the edits up to that point that created the resource. This is an update, but is not the raw sequence of events.
I don't see what's too fundamentally different about Braid that it needs a new status code and protocol. Shouldn't SSE use 209 then?