When I've been thinking about adding a built-in connection pool, my rough plan was mostly "bgworker doing something like pgbouncer" (that is, listening on a separate port and proxying everything to regular backends). Obviously, that has pros and cons, and probably would not work serve the threading use case well.
And we will get the same problem as with pgbouncer: one process will not be able to handle all connections... Certainly it is possible to start several such scheduling bgworkers... But in any case it is more efficient to multiplex session in backend themselves.
pgbouncer hold all time client connect. When we implement the listeners, then all work can be done by worker processes not by listeners.
Regards
Pavel
But it would have some features that I find valuable - for example, it's trivial to decide which connection requests may or may not be served from a pool (by connection to the main port or pool port).
That is not to say the bgworker approach is better than what you're proposing, but I wonder if that would be possible with your approach.
