> Sorry but I haven't really seen this pattern anywhere, care to give some examples?

The standard library provides examples, including a "storage" example.

> All libraries that I recall ever using always export a single package

Right, and now there are questions around the language being spoken, so to speak. That's the power of idioms – it avoids the reader needing to ask new questions when encountering language that is new to them. But idioms are not the be all, end all. Sometimes they just don't fit. And if that's the case in your situation, no problem. Nobody knows your problems better than you. To listen to someone else tell you how to solve your own problems is foolish.

That is why I earlier wished we had seen some real code. Perhaps then we would understand the nuance that has lead to you choosing these particular tradeoffs. We have no sense of what problems you are actually trying to solve. As a rule, though, an overarching interface package with consumptor functions and multiple implementation packages is preferable because then it avoids a lot of the questions developers are going to start asking.

For example, with the alternative suggested, what if I want to add a new storage adapter that conforms to your interface? Do I need commit rights to your package or should I create my own package that satisfies your exported interface? If I create my own package, why is it the lone implementation in its own package while the others are all rolled up in one package? Is it that you don't want third-party implementations for other services not covered by your package? Why is that? On and on...

If you stick to the idioms, those questions are already answered by convention.