Code change:
StreamPriority ensures that limited resources can be directed to the most important streams first. <del> HTTP/2 adds a new interaction mode whereby a server can PushResources.  Server push allows a server to speculatively send data to a client that the server anticipates the client will need, trading off some network usage against a potential latency gain.  The server does this by synthesizing a request, which it sends as a PUSH_PROMISE frame.  The server is then able to send a response to the synthetic request on a separate stream. </del> Because HTTP header fields used in a connection can contain large amounts of redundant data, frames that contain them are FieldBlock. This has especially advantageous impact upon request sizes in the common case, allowing many requests to be compressed into one packet. <ins> Finally, HTTP/2 adds a new, optional interaction mode whereby a server can PushResources.  This is intended to allow a server to speculatively send data to a client that the server anticipates the client will need, trading off some network usage against a potential latency gain.  The server does this by synthesizing a request, which it sends as a PUSH_PROMISE frame.  The server is then able to send a response to the synthetic request on a separate stream. </ins> 2.1. The HTTP/2 specification is split into four parts:

Related discussion:
text: NAME says: It's not very widely used and many implementations either don't support it at all or don't support it in a way that improves end-user performance. This sparked a lively discussion at URL
I’m open to dropping this, but I think the case needs to be be made for what the burden is. It’s one of the easiest protocol features to just ignore: send SETTINGSENABLEPUSH=0 and then you can remove all awareness of PUSH_PROMISE from your state machine altogether.
Crazy thought: what if we made part of HTTP/2, and then factored server push into an extension?
Or what if we minted a new ALPN () and flipped the default value?
Or left it as is, since it is used outside of browsers. The browsers have an API problem that has not been solved, and it is unlikely that push will be effective there (except as a competitor to inlining) until that changes.
I have no particular objection to flipping the default under a new ALPN. Factoring it out to an extension is harder, but not impossible -- it's pretty embedded in the state machine, but we might be able to abstract that away. Removing it entirely seems challenging for several reasons. The purely process one is that RFC 8030 requires Server Push, and removing a feature used by a Standards Track RFC presumably requires deprecating that other RFC.
I should note that my preferred outcome here is "do nothing". I'm just spitballing ideas.
Flipping the default if we mint a new alpn seems sensible based on the comments above. This would also align with HTTP/3. Moving it to an extension is probably more work than it's worth, I'll admit. I wasn't aware of RFC 8030. Is that an actively used RFC?
Push is being used outside of browsers (curl supports it, once implemented for a particular company that uses/used it pretty widely across the globe), although I suspect that outside of browsers we also have no real means of figuring out exactly how much or little. Saying "do it in extension" will probably equal killing it, but I also think that removing it from the spec is more work than its worth and just toggling the default seems like the best middle ground.
We may want to be a bit relaxed about flipping the default.