Having these not in the CL ExecutionPayload makes local verification of EL block_hash complicated for the CL.
Generally, all of the new EIP-7685 “general purpose execution layer request” tend to share some of that, but the types 0 and 1 are at least somewhat mappable back to something of which the block hash can be computed by an optimistically syncing CL (while EL is undergoing maintenance, it cannot answer INVALID_BLOCK_HASH so the CL has to do it internally).
I’d advocate to try and replicate the three lists (deposit receipts / withdrawal requests / consolidation requests) into the EL block header as separate fields (instead of EIP-7685), and/or to create a EIP-6493 style StableContainer as their union, given their overlapping nature in common fields.
Currently the EIPs seem a bit… ad-hoc to me, which is alright for the initial devnet, but should be cleaned out later on.
Furthermore, all the extra BeaconState fields break trustminimized Merkle proof verifiers for decentralized staking pools such as RocketPool. It should be considered to combine this with EIP-7688: Forward compatible consensus data structures.
Have put it on the ACDE agenda as well: Execution Layer Meeting 187 · Issue #1029 · ethereum/pm · GitHub