Alternate approach #3
Description
You are probably aware of this, but there is another approach that you don't address in your README. In this approach, the library provides a 'using' macro that the consumer of the API can use to create a single purpose module with the appropriate parameters.
The mailer 'Swoosh' is a good example of doing this. This is the entire contents of one module in my system:
defmodule DoorstepWeb.Mailer do
use Swoosh.Mailer, otp_app: :doorstep
end
Then, rather than calling Swoosh directly, I call DoorstepWeb.Mailer and the use directive has created all the API functions I need, with the appropriate adjustments (presumably passing through to equivalent internal functions, adding otp_app as an extra arg).
In this case you would only ever need one implementation, but if it was being used to inject some other form of dependency (like a mailing provider), you might instantiate several and then use the appropriate module in your code.
There is a downside of greppability, and of having a per-library macro burden to make it work. It's quite natural to the consumer though.
[by the way - I hope it's ok to put this here]