I am not sure if an undisciplined collection of names, or even a collection of names and associated “general idea” labels, is a good idea. Such a collection risks becoming a source of type puns that confuse users and developers about what contracts the functions are supposed to have.
Two methods whose parameters are different abstract types and have no traits in common are, in my opinion, different functions. For example, in one post @Tamas_Papp said
Even within a single package, two versions of StatsBase.sample have parameters n_chains and nchains. Once multiple packages and dispatch get involved, it’ll be even more confusing.
I think it would be helpful to have declared bounds on what shared parameter names and types or traits a function accepts and returns.