(2) How come "simply check the specs for inputs and outputs to remain unchanged" helps with trustworthiness or gives _any_ assurance of the incorrect implementations? (unless it's agda/coq, but we are not talking about them). The specs can say whatever, and yet the program might full of bugs.
(3) How do you select a library in an area you are not familiar with? It seems you know cryptography well, so let's choose a different topic - what would you examine to find, say, good audio capture library, or a good OpenGL wrapper? For me, I'd look at popularity (by number of reverse dependencies in my repo, mentions on the web, or github stats); liveness (activity in repo and mailing list, open/closed bugs); general quality (commit history, CI logs if they are public, etc..). All of those would be _vastly_ easier with a single large repo vs tons of smaller one.
(4) Think of few supply chain compromises that come to your mind. How many of those would be prevented by "distributed replication or transparency logs"? I've thought of xz compromise, left-pad pull and Marak's colors.js. _None_ of them would be fixed by "consensus on dependency versions and their hashes". All of them would be fixed if people just kept packages bigger, so that every one has actual CI, release team, and so on.