Why is this article recognizing only two extremes? Either everyone uses the same instance, or there's NO SHARING AT ALL:
"Re-introduce duplication by inlining the abstracted code back into every caller."
Or maybe if there are, say, 10 places dependent on the shared code, we can make them 5 places dependent on one version and 5 places dependent on another?
Forking and merging is part of business as usual in programming and we should be used to it. We should not be shocked that sometimes you have to fork a function because adding more parameters is not feasible, but nor should we declare sharing is therefore wrong or harmful.
Also, how you design parameters is extremely important. One callback parameter may be worth a hundred "normal" ones.
The point she is making is about choosing to go back, towards less abstraction, rather than forward. So I expect the answer to your question is that two endpoints are enough to establish both directions and make the intended point.
If midpoints are introduced then comments like yours "but what about..." can always be made until the entire abstraction tower is fully described, and that's not the blog post (or book) the author wanted to write.
I wish every time someone established two extreme points, everyone is like you, automatically interpolating an entire space of endless possibilities, countless shades of gray. But this is decidedly NOT how we think, because dichotomies are simpler to mentally process, and in fact ultimatums or "single right solution" situations are easiest to process.
Have you ever seen an online argument? If someone is right, and someone is not AS right as they are, they are a "left shill" and vice versa. If you promote solution A, and someone promotes solution B, then they're "wrong". Not establishing points, just "wrong".
So I think establishing two directions is best accomplished not by marking up two extreme points and leaving the rest to the imagination as our imagination is apparently quite poor.
It's more correct to describe the next step in a direction, and let us take things step by step and know that nuance is inherent to our success, not optional.
Of course. The best of all is to let go of all dogmas about coding. But we will not get there by either blog posts or comments, it requires education over time.
"Re-introduce duplication by inlining the abstracted code back into every caller."
Or maybe if there are, say, 10 places dependent on the shared code, we can make them 5 places dependent on one version and 5 places dependent on another?
Forking and merging is part of business as usual in programming and we should be used to it. We should not be shocked that sometimes you have to fork a function because adding more parameters is not feasible, but nor should we declare sharing is therefore wrong or harmful.
Also, how you design parameters is extremely important. One callback parameter may be worth a hundred "normal" ones.