It would be great to implement the auto-resizing as an additional "layer" on top of the generic pool implementation. How about we only add a resize() to the generic pool and then have a separate AutoResizingPool or so that uses the generic pool and only contains the resizing behavior logic.

I’m pretty sure that’s in general a very good idea. This week/month in particular, well—I added this patch to your package because unexpected corner cases in a more generic pool package, combined with threads for basic workers, bit me in the ass (in this case generic-pool and the surprising fact that borrowed + available !== size!). So in part, what I was trying to achieve here was dynamic pool size without trying to be so generic as to be potentially surprising, because while being generic has tremendous benefits, premature generic-ness is almost as bad as Dijsktra told us premature optimization is…

Well, I’m not trying to be disagreeable; I love this package, I'm very happy with how receptive you are to contributions, and your general point is entirely sound; but (from my POV) it needs to not be desperately/excessively generic, and I’d like to keep a nice, simple API like this, so I may not have the resources to refactor immediately.