Assuming that a server is dealing with a buggy client, it seems like a good idea to have a mechanism that tells the client to GOAWAY, and don't use this protocol when coming back.
As an example, if a server detects that the client is not responding correctly to flow control, the server could instruct it to not use HTTP/2 until the client is restarted (or similar).
This is likely not useful in the client->server direction.
I think of this as similar to alternate-protocol, though it should not need a request to indicate that the protocol should not be reused.
It would be impractical to use this on the client->server direction for a number of reasons:
1) The server would have to store millions or billions of entries
2) There is no guarantee that a single server is dealing with the client, even if the client is connecting to one IP
3) A single client should not be able to stop a server from serving HTTP/2 for others.
A big question is:
Is this sufficiently different from PROTOCOL_ERROR that it is needed (I view that as the why, as opposed to what to do)? If not, should we have suggestions about appropriate behavior in response to PROTOCOL_ERROR?
In my view, yes and yes. This is important because the server should not be forced to disable HTTP/2 support for everyone in order to work around a buggy clients, and because the server cannot have the appropriate information (IP is not enough in this world of NATs and proxies) to determine that the client is a bad one. Client version strings could give some hint... but there is no guarantee that the client version string announced actually is the client in question.
Speaking from experience, it is far far worse to have a set of clients which end up in a persistent state of non-connectivity than to have worse latency. If either side detects that this is happening, then either side should be able to make this decision.