Maybe someday we should have all that, but I think for right now that's complicating things unnecessarily. I think the best proposal so far is to allow the host=X option to be repeated multiple times. If you repeat the host=X option N times, you can also repeat the port=X option exactly N times, or else you can specify it just once. Done.
But this already breaks backwards-compatibility with any clients who belief that whatever value specified the latest takes precedence. I'm not arguing that there are such use cases in the wild or that it's entirely sane thing to do, but still.
More importantly, this will break any code that tries to parse the conninfo string and produce a hashmap from it for modification.
Alternatively, leave the host=X option alone and add a new option hostlist=X, allowing a comma-separated list of names or IPs, with each hostname or IP allowed an optional :port suffix. If host=X parameter is omitted or the connection to that machine fails, try everybody in the hostlist concurrently, or with some configurable (and presumably short) delay between one and then next. Again, done.
The exact behavior in case of both host/port and hostlist are specified becomes really tricky then. It's already tricky enough, if you recall the service files -- how are they going to come into play here?
I believe the less there are implicit workings in the way libpq connects, the better.
Alternatively, change the rules for parsing the existing host=X parameter so that we split it on some separator that isn't a valid hostname character, and then strip off an optional :port syntax from each entry; that value, if present, overrides port=X for that entry.
It's tempting to use ':' as the separator here, but it's still valid for directory names and host can be one in case of UN*X sockets.
