I've never seen an adequate answer to this but it boggles my mind that this problem wasn't foreseen.

When Git came out we'd already seen a move from MD5 hashes to SHA-1 because MD5 was no longer deemed secure. Of course this was going to happen again.

So why wasn't the protocol and the repository designed to have multiple (hash algorithm, hash) pairs?

At this point it becomes a client and server issue if you support a given protocol or not so you have this handshake to agree on what you're using (eg a server may reject SHA-1), much like we have with SSH.

This seems like it would've been trivial to allow for in the beginning. Or am I missing something?

I don't think you are, and the IPFS ecosystem has already run into this problem. In IPFS, content is addressed by its hash, but different protocols are better suited to different encodings - browsers speak http, which is case insensitive.

And so they've worked out self-describing hashes! https://multiformats.io/multihash/

The basic idea is that you include the name of the algorithm as part of the hash. This allows changing the hash algorithm without breaking backwards compatibility.

It's a cool standard with implementations[0] for many languages. I don't know if it was considered for git, but it does seem likely that this issue will come up again before the end of time :)

[0]https://github.com/multiformats/multihash