Perhaps I’m confused here, but there are two values floating around for a block:
- the value to the builder
- the value to the proposer
If you are calculating 1 then there is no benefit to a builder to include transactions that inflate the value, as it would give the impression that the builder is keeping a larger portion of the MEV for themselves. If you are calculating 2 then re-entrancy doesn’t apply as what matters is the delta at the end of the transaction, not each movement of funds within the transaction. So sending 1 Ether to an account, it being sent back via smart contract, and sending it again would only result in a 1 Ether difference in the receiving account’s balance over the lifetime of the transaction.
If the proposer provided an address which was a smart contract that sent all funds to another address on receipt then this would result in the value of the block being under-reported, however this seems to be a limited use option and if a node operator attempted to do this it would be picked up pretty quickly and flagged. So I don’t see this as a reason to move to a significantly more complicated system of accounting.
(If it is really that much of an issue then you could trace the entire transaction to account for situations where funds move in and out of an account in the same transaction, but that would be relatively expensive and quite likely to be more open to abuse itself.)