The leftpad problem was that an author unpublished a package, breaking everything that depended on it.
What does that have to do with naming?
The uniform naming policy relies on usernames forming canonical package names, and the leftpad situation was caused by similarly coupling packages to npm user accounts. The point is that neither usernames or user accounts should be treated as fixed or immutable; users should be able to change both, given that it’s tied to their idenity, but a package manager should also give a guarantee that dependencies will continue working. This guarantee is not possible with Elm’s current package system, and the uniform naming policy is predicated on the current system.
The uniform naming policy exacerbates the problem of lack of dependency guarantees by making it harder to get rid of the username namespaces, and it also exacerbates the other major problem of the current system, which is potential module name conflicts.
One more unaddressed concern is the relation of harder to type usernames and typosquatting by malicious packages. It’s a serious problem at npm’s scale, arguably much more so than undescriptive package names.
The whole discussion whether it’s more valuable to memorize package branding or author branding is a distraction in light of technical problems, but names like elm-graphql aren’t even that descriptive, much less perfect; I mean, some of the libraries with that name are query builders, others are code generators, and the name would also apply to utility libraries with an even more different scope.
You contradict yourself with the example of Elm; there isn’t a perfect but taken descriptive name that the name Elm would have been chosen in lieu of. A lot of projects don’t have obvious names, and a lot of random names are random just for stylistic reasons. It’s a silly just-so story that names like “axios” would be about perfect names being already taken instead of the authors, for instance, thinking that “axios” sounds cool, just like how Elm was ostensibly named.
