When you're building a library, or any tool that will be used by many people for different purposes, this is a problem, because they all have different needs.
What I try to do is get some representative use cases, and make sure my product makes a reasonable choice for those cases,
and is not atrociously bad in any case.
If I can just give one example of what can happen:
The LAPACK routine DGEMM is a general routine for multiplying matrices.
Its calling sequence contains initial character arguments for specifying certain options, like whether either argument is to be transposed.
The customizing arguments are in there for two purposes: to make programming easier for the user, and to make it easier for the library writer.
Without them, either the user would have to transpose the arguments him/her-self, or the library writer would have to provide multiple routines.
To handle those arguments, DGEMM calls a function LSAME that compares characters. That also makes life easier for the library writer, because character representation can be very different for some machines.
The downside of this is, if the matrices are not very large, that DGEMM spends most of its time calling LSAME, compared to the time it spends multiplying matrices!
If the user's program spends a large fraction of time calling DGEMM, that means a large fraction of time is spent calling LSAME, comparing characters (even though those characters are practically always the same).
Repeated effort is wasted effort.
If a user can figure that out, such as by random pausing, they can make ad-hoc routines for multiplying their matrices.
But the more general point is -
that is the problem in writing libraries or any tools.
You have to try to be useful for a spectrum of needs.