The removal of Channel#full? and #empty? was intentional. They leaked state of the channel in a way that can’t be guarantee. The sender of a buffered channel should not need to be aware whether the send will block or not (same way for the receiver).
If there is a need to limit quota then I suggest splitting the task and using some fibers for that only. At the end of the day there is already a fiber to accept each request. I don’t expect to be much different.
@jgaskins regarding the connection pool logic exposed, the creation of them are serialized. That is an unneeded penalty you are exposing to simultaneous clients. In crystal-db that is addressed by unlocking during the creation of the connection but counting the number of connection been created.