What guarantees do we offer about the formatting of exception responses? Today the docs give some examples but do not accurately describe the bits on which clients can rely, and our responses are quite different if the user sets http.detailed_errors.enabled: false which breaks clients that are overly strict about these things. It's unclear whether there are other situations that might result in differently-shaped error responses.

Some YAML tests assert things about error.type and error.reason and so on, but we don’t run those tests with detailed errors disabled (they would fail if we did). I believe there are more clients out there making decisions according to parts of the response (e.g. error.type) which may not always even exist, or may be unstable because they’re not covered by any tests.

It would be very helpful to clients if we could describe a general structure for error responses, and somehow guarantee that however we're configured we always follow the correct structure.