One could argue that, syntactically, any problem+json content would also be valid json content. So, by that rationale, accepting the latter could be seen as implying also accepting the former by extension.

No, +json types are not "subtypes" of application/json. I understand the rationale. application/json only says something about the syntax, not the format, and +json (and +xml) types say something about both the format and the syntax.

In other words, whilst we can assume that an Accept including application/json will be able to parse the problem JSON response, we cannot assume it will be able to process it.

I.e. if a request's Accept header specifies application/json but not application/problem+json, would it be valid to deliver a application/problem+json response?

It depends on if you want to content-negotiate or not. It is acceptable to not content-negotiate when an error is encountered. Serving Content-Type of x ignoring Accept is fine. You are not negotiating any content-type, but interpreting y to mean x is not intended (or valid in terms of Content Negotiation).

The appropriate thing to do is to serve a 406 Not Acceptable (or 415 Unsupported Media Type, when you have the same question for processing a request body), and we can help the user by being really helpful. For example, when a user-agent sends our apis application/json (among other things), we will show a HTML page with:

Please choose one of the following types:

This endpoint tried really hard to show you the information you requested. Unfortunately you specified in your Accept header that you only wanted to see the following types: application/json.

Please add one of the following types to your Accept header to see the content or error message:

1. application/vnd.delftsolutions.endpoint_description.v1+json

2. text/vnd.delftsolutions.docs

3. */*

4. text/*

5. text/html

6. application/vnd.opus-safety.site.v1+json

7. application/vnd.opus-safety.site.v2+json

8. application/vnd.opus-safety.site.v3+json

9. image/svg+xml

10. image/*

In case of an error, application/problem+json will be in this list, which is automatically rendered.

We tell our API consumers to interpret the Content-Type to be able to extract the error message.

So I am unsure.

In general, when you're following standards and you are uncertain, doing what's most "helpful" to you can often be the best choice. In this particular case, responding with a problem when someone is requesting json will likely make it harder to debug logs, so I wouldn't recommend it!