Code change:
We left open pending some explicit text about the double GOAWAY graceful shutdown. Here is some proposed text that we can iterate on. One difference from what we discussed is the first GOAWAY has last-stream-id of 2^31 - 1. The calculation based on MAXCONCURRENTSTREAMS isn't really needed and just opens up implementations to bugs.
I first brought this up in URL but I wanted to open an issue to track this as I believe this is a design flaw with HTTP/2 as it is today. Consider an HTTP/1.1 connection to a proxy that speaks HTTP/2 to the server. If the server needs to shut down, it will send a GOAWAY acknowledging the last request it processed. However, there is a race condition where a request could be in flight or queued. When the server eventually sees the delayed requests, it will not process it and the proxy will eventually return an error (most likey 5xx) to the client. Requiring proxies to buffer the request in order to replay for this case is not feasible. One solution is to have the server send an ALTSVC frame, but this is not ideal as it implies each server must keep track of a list of alternatives. It may not make sense for the origin server itself to maintain this (potentially quickly changing) list. Another solution is to allow acknowledging unreceived streams in the GOAWAY. For instance, the server could acknowledge last-stream-id plus SETTINGSMAXCONCURRENTSTREAMS. This might work in practice, but seems hacky. Another (and in my view best) solution would be to introduce a two phase shutdown mechanism. Some strawman language: "If a server needs to shut down for maintenance, the server SHOULD immediately send a DRAINING frame on all its client HTTP/2 connections to indicate that it will soon shut down. This allows the client to stop issuing new requests and avoids unnecessary retries. After a reasonable amount of time, the server SHOULD send a GOAWAY with status NOERROR on all its connections and then close the connection. Clients MAY may open new connections to the server after receiving a DRAINING frame."
I have added some text in URL that covers some of this. I'm going to leave this one open, because I don't think that this is completely done yet. We need to discuss whether we want to be more explicit about this particular use case.
Discussed in NYC; double GOAWAY sounds good.

Related discussion:
text: clients to abandon automatic retry of requests if a GOAWAY frame is lost. <ins> A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.  This is especially true for intermediaries that might not be serving clients using HTTP/2.  A server that is attempting to gracefully shut down a connection SHOULD send an initial GOAWAY frame with the last stream identifier set to 2 -1 and a code.  This signals to the client that a shutdown is imminent and that no further requests can be initiated.  After waiting at least one round trip time, the server can send another GOAWAY frame with an updated last stream identifier.  This ensures that a connection can be cleanly shut down without losing requests. </ins> After sending a GOAWAY frame, the sender can discard frames for streams with identifiers higher than the identified last stream. However, any frames that alter connection state cannot be completely