My understanding is that to be able to prove some value in the beacon state, we also need to know the generalised index of the property we wish to prove (or more generally the depth of the merkle tree representations of the objects in the path with which we can compute the generalised indices of properties).
It seems likely (and is already the case in Capella) that the consensus spec containers will be appended to in future forks and so the depth of their tree representation may increment and therefore all the generalised indices of the existing properties will change too.
The consequence of this is that any smart contract that verifies proofs will need some sort of upgradability to be forwards compatible with future changes to the beacon state object.
This seems to break some of the fundamental usefulness of having the state root available on the EVM because proof verification logic cannot be made immutable. Previously, we had to trust an oracle to submit the correct state about the beacon chain. Now, we have to trust the contract owner to upgrade the proof verification logic as required by future consensus spec changes.
Unless the proof verification logic was also made part of the EVM via a precompile or something.
Am I missing something?