Upgradeable means the storage layout is forever

I come from ABAP, where nearly everything can be changed in place, and that is not better, for what it is worth. Change a domain or data element in the dictionary and every program that typed its variables against it with TYPE picks up the new definition the next time it is generated. That sounds kind until an old report that copied the field into a hand-written TYPE c LENGTH 10 starts cutting values off without a word.

So I agree with append only, and I would add one thing to the review. Search for every place where the old shape was copied by hand. Those copies don't follow the dictionary. For a contract I would expect them in off-chain scripts that read raw slot numbers.

Never used Solidity, but the habit I'd bring is keeping the previous caller beside the new version, except here the previous caller is the stored state itself. A layout comparison tells you nothing moved. It can't tell a future reader why a slot that looks unused has to stay exactly where it is, so I'd write that down next to the code at every release.

One exception to the constructor paragraph, and it cuts both ways. An immutable assigned in the implementation's constructor is not in storage at all. The compiler writes its value into the runtime code, so a delegatecall from the proxy runs code that already carries it. The value does come through the proxy. It is also shared by every proxy that points at that implementation, and it changes only when the implementation is redeployed.

So an immutable is fine for something that belongs to the code version, such as a fixed dependency address. For anything that should differ per proxy it is the wrong place, and a storage layout diff will not show it, because it never had a slot. Does your review read only the storageLayout output, or the immutables as well?