The idea that code needs to be distributed in libraries rather than functions is limiting, especially for these little independent functions. I've always liked this proposal from the creator of Erlang, but afaict it never went anywhere: http://erlang.org/pipermail/erlang-questions/2011-May/058768...
I thought it would be cool to build something like this on top of ipfs. Even larger opinionated 'modules' could be defined from the smaller building blocks. The "names" of the content-addressed functions would not be human friendly, so some sort of local aliasing would be a must. A blockchain approach can be used to define upgrade and downgrade paths implemented by the same signers, but it would be up to the caller to update their call if desired. Old code that is not used anymore would eventually be forgotten by the network. Rather than having an "approved database" of functions I'd considered an overlay of alias-groupings that could be published independently for different applications.
Yeah, human names will always be somewhat messy/heuristic/political. There's also a matter of curation of code into searchable, semi-reliable lists. It makes lots of sense to decouple that from the actual code and enable competing names, repo's etc.
See also Hoogle [1], a Haskell API search engine that allows you to search by aproximate type signature. It works really well.