What's wrong with dynamic pooling? Once you hit limit, "goal post" is moved and you have more objects in your pool. There would be (unnoticeable) delay with instantiating one new object to add to the pool, but once it's done, limit is increased.
The real danger comes when the player has the ability to instantiate objects in some way. If there is no way to stop them from creating new objects, they can theoretically keep making objects until the game crashes. Dynamic pooling is better than no pooling, but doesn't address the issue with player-prompted object creation. Without some form of hard limit, there's nothing to stop the player from eventually crashing the software.
A reasonable approach would be to combine standard object pooling with the dynamic approach you mention. You could create a pooling system with an initial limit and an upper limit. When the extra space is available, the pool will delete existing objects in order to bring the pool down to the initial limit.
Of course, at that point you're pretty much re-creating standard garbage collection, and what would be the point? This is part of the reason why a more standard object pooling approach is valuable, because it is different from the default memory management approach. There is such a thing as over-engineering a solution. Basic object pooling is a fairly simple approach that has a proven record of success.
Community
