I don't love this.. Specifically the fact that PostgresException inherits the Code property (since it extends NpgsqlException), so people will likely think that's the interesting property; but it isn't (SqlState is).

After thinking about it, I 100% agree. Ideally all information about error conditions would get conveyed via SqlState.

Ideally there would be some code-space reserved for drivers or whatever in SqlState, so we could allocate codes there and just promote SqlState to be on NpgsqlException... But I can't see anything like that, and it's beter not to mess with it.

No, I also cannot find "some code-space reserved for drivers" but perhaps your "whatever" part is a solution.
After looking at SQLSTATE once again, I found out about the "HY" error class which seems to be the class for "Call-Level Interface" errors and if you look up what this means, you can find out, that while it was originally developed for C and COBOL interfaces, ODBC is one of the most widespread users of the standard.

Looking how some ODBC drivers report the fact that they ran out of connection handles, HY014 seems like something one could (ab)use to communicate the fact that the pool was exhausted (given the fact, that a "proper" implementation of a spec that was written for C in the 90ies will probably never happen in .NET in any case).
In general I think that the HY class will probably never come from PostgreSQL itself (at least it does not appear in their docs for now), so we might consider it as a code-space, that is not formally reserved, but in a way intended for the use of drivers and prefer finding and assigning a somewhat fitting code from that class instead of inventing a completely new coding system for Npgsql.
Maybe ADO.NET drivers could even standardize on some common codes for common problems and by that provide a somewhat more generic solution to this problem.

What do you think?