I would always consider such questions behaviorally, from the point of view of which clients will take care of this aspect of the answer and that this will affect these clients.
So, in particular, which customers care and use the Accept header, and what are the implications for these customers?
Firstly, there are web browsers. My initial thought was that if you are using CORS, the value of the Accept header may be related to the web browser and you might need to enable POST . However, these are actually Access-Control-Allow-Methods . Therefore, as far as I know, the Allow header does not have any behavioral consequences for browser clients.
Then there are software clients. In such cases, non-overloaded methods are most likely the ones you want to list. (For example, you might have a client for creating documentation that checks and displays valid methods, and also makes sense from the user's point of view.)
Finally, there are users who visually check your API responses. In this case, I would probably prefer the overloaded set of methods again, as being more informative.
In short - I would probably just list an overloaded set of methods that are allowed, and not including POST . Usually, the browser is the only client that will perform overloaded requests, and I do not know that it uses or checks the Accept header in any way.