What is the Contract Registry pattern, and how does it enable "upgrading" immutable contracts?

Keep an on-chain registry mapping a stable, human-readable name to the address of the latest version of a contract; callers resolve the name first, so deploying a new version and repointing the name upgrades everyone without touching the old, immutable code.

• Problem. Deployed contract code is immutable, yet applications need to fix bugs and add features. And a raw contract identifier on Ethereum is an unreadable hexadecimal address.
• Solution. An on-chain registry contract stores a mapping from user-defined symbolic names to contract addresses; its own address is advertised off-chain. To call a contract, you first look up its current address in the registry. Upgrading means deploying a new version and replacing the old address under the same name — dependents keep using the name and don't break. The registry can gate who may update it, and all previous values remain on-chain.
• Benefits. A human-readable, constant name that survives upgrades, transparent upgradability, and version control.
• Drawbacks. Limited upgradability (if other contracts call a function directly, its interface/signature still can't change without breaking the link — hence versioning and deprecation flags); cost (maintaining the registry, plus a lookup on every inter-contract call).