Consistency in Stream Beginnings in HTTP/3

This discussion has happened across a collection of GitHub issues with largely the same participants, and I'd like to get a sense of the larger working group's opinion before I work on any of these directions (or close all the related issues).

To recap the current state:

  *   Unidirectional streams begin with a type byte; interpretation of the remainder of the stream data depends on the type
  *   Push streams continue with a header - the Push ID as a varint - followed by frames as usual
  *   Control streams don't have a header; frames begin immediately after the type byte.  However, a SETTINGS frame is required to be the first frame of the stream.
  *   SETTINGS cannot be sent again thereafter or on any other stream

That means there are currently two different models of how you put required-to-be-first information:  As a required-initial frame or as a header before framing begins.

There are a couple of paths forward that have been discussed:

  *   Stay as-is.  SETTINGS is a frame in HTTP/2, so we're keeping it that way for consistency.  We've previously decided not to permit changes to settings to avoid the question of synchronization.  The reasons to change are not urgent.
  *   Make the Push ID a required-initial frame.  Proposed in #2526; rejected in London.
  *   Make SETTINGS a stream header.  Proposed in #2783.
     *   Argument for:  Gets rid of the concept of required-initial frames, in combination with #2781.  Consistent with the Push Stream header.
     *   Argument against:  Push ID isn't a length-prefixed structure, just a single varint.  We already have facilities for reading length-prefixed structures in frame handling.
  *   Allow multiple SETTINGS.  The synchronization requirement on SETTINGS is hairy when values are reduced, because in-flight activity might now violate a peer's restriction.  Allowing SETTINGS to be sent at any time, but only increase values, would also mean they need not be the first frame, eliminating the concept of required-initial frames.
     *   Complication:  What does this mean for clients' remembered settings and server's remembered settings as stored in NSTs?  If a client updates stored settings but retains a NST from earlier in the connection, the server and client could have divergent views of the server's settings on a future 0-RTT connection.
  *   Allow omitting SETTINGS.  If the server doesn't need to change anything from the client's initial settings, then the server can just not send a SETTINGS frame.  Once you've sent something else on the control stream, though, you can't send one later if you change your mind.

Thoughts?