Yes. 200, 301, and 404 are top-tier status codes that even the simplest system can't help but handle in some sensible manner. In the second tier you have the necessary support for partial content and basic content negotiation. After that is when it gets a lot more complicated.

The fact that "browsers render 404 pages" won't save you when you try to get "clever", err, I mean, "standards compliant" and serve a complicated HTTP page out on 402. It probably won't confuse browsers, which will probably just render the page and leave the user oblivious a 402 occurred, which is precisely why I included "(not browsers, but other ones)".

Browsers are forced to march together in some semblance of lock step. When you step out into the heterogeneous world programming language APIs, "convenience" code written on top of those APIs, frameworks written on top of that convenience code, internal libraries written on top of those frameworks... yeah... you can't get very many complicated semantics through that sort of pipeline. And that's not a terribly unrealistic pipeline, unfortunately.

If 402 had actually become part of a means to get paid it would have quickly joined that list of top tier codes right behind 200.

Don't forget these popular code. You were probably 301/302ed at least once today. 201 is popular too. In fact you probably have to do something that will give you a 201 before you get your 402.

301 Moved Permanently 302 Found 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 410 Gone 500 Internal Server Error 501 Not Implemented 503 Service Unavailable 550 Permission denied

What you are saying is true; what I was keeping myself confined to are the codes that you have reasonable assurance that the client will actually do something with. A lot of those codes will not cause the client to do anything terribly specific, like "follow a redirect"; it'll just return the content as if it was a 200, and if it's an API, maybe return the request as failed, but that's about it. In the vast majority of cases, clients don't particularly care if they get 400, 401, 403, 404, or indeed, 4xx.

I wonder if there's even a single client in the world that will get a standards-compliant 412 Precondition Failed and try a second request with a different set of conditions. Or indeed do anything sensibly different at all vs. having received a 404. (I specify "standards-compliant" because I'm sure there's plenty of APIs that use 412 for something non-standard.)

Most modern browsers do.

> The HTTP 418 I'm a teapot client error response code indicates that the server refuses to brew coffee because it is a teapot.

I wonder how FF/Chrome would react to this!

By just rendering it: https://httpstat.us/418