Thanks for the link, @valeriomazzeo!
I think there is definitely potential for this!
Earlier this year our team published a connection monitoring and pooling specification. This defines a standardized approach for how all MongoDB drivers should pool connections. (The monitoring bit involves publishing events in some language-specific manner when e.g. a connection is checked out or back into a pool.)
As libmongoc doesn't comply with this specification right now, we don't either, though we've mostly retrofitted the desired pool API atop their version of pooling. When we get to writing the SwiftNIO-based implementation, we'll want it to fully comply with this spec.
We'd be very interested in taking part in any discussions on this going forward and seeing where pooling needs overlap and differ across drivers and whether it makes sense to share any/all of a pooling implementation.
As I noted in the pitch above, the pure Swift implementation won't be coming for a while longer, and when it does it will occur in pieces rather than being a complete rewrite all at once.
Along the way, we'd certainly like to collaborate with you and the rest of the community on components that are useful to DB drivers and the server-side ecosystem as a whole, e.g. the DNS client you pitched a while back, connection pooling, etc. On the driver code itself, in general the official MongoDB drivers are owned by our team, but welcome collaboration via pull requests, GitHub issues, JIRA, etc.
We considered this, however, adding new BSON types is a pretty rare occurrence (e.g. the last addition Decimal128 was 3.5 years ago). We felt that the benefits of the new approach (being able to exhaustively switch on BSON types, less verbose construction of document literals, being able to fully hide implementation details that were previously on the public protocol, removal of "placeholder" structs containing no data such as BSONNull) far outweighed the potential risk of some potential breaking change.