I can certainly identify with this.
Having done enterprise java for so long, I strive to be as reductionist and minimalist as I can be in order to avoid dependencies outside the JDK.
Vying for "you aren't going to need it", trying to keep things as simple as I can.
But it also comes down to not overcomplicating stuff we've already written.
Obviously there's an urge to reuse your own libraries, but you have to strive to not overcomplicate them as they're applied to new use cases as you drive the peg in to a rounder hole.
It's very easy to FactoryFactoryFactory in Java, but flexibility and configurability leads to complexity and black hole of combinatorial testing.
Almost better to fork the earlier library and hammer it to fit the new space without regard to its old use in the other system. But that leads to file replication (notably files of the same name doing subtly different things). And there it's a challenge to go "gee which one should I use" when you're working on version 3, when what should be happening is "pick the best one" and keep hammering.
We used to have our general purpose "catch all" library which, in the end, indeed, "caught all". "Oh look, somehow I have jars from Clojure, Groovy and Scala, when all I wanted was a URL Builder."