Interesting. May have to keep an eye on this.

Hmmm... error docs to coincide with api docs? Seems a bit HATEOS but I can see it having functional purpose for API implementation/usage

This borders on "functionality as output" though wherein we are creating further bindings of communication/business logic (rather than abstracting them for distributed architectures).

The question I have is how would the spec be implemented to allow for an API abstraction (ie RAML, API Blueprint, OpenAPI) to be aware of what errors could be returned?

Also,Is this always going to be based on 'application/problem+json' content type being sent? Does content-type now dictate whether data is returned?

Alot of questions...