The aggregation rule under requestId == 0 reads naturally if you treat the controller’s pending balance as a single pool. Under that reading, redeem(80) is a partial redemption of the 100 claimable shares, leaving 20 still claimable. The spec doesn’t say partial redemption is forbidden, only that pending and claimable states are aggregated, and the existing redeem(shares, receiver, controller) signature already accommodates the partial case because the caller specifies the share amount.
The case where this gets uncomfortable is if implementations have any per-request state that survives aggregation. For example, if request 1 (30 shares) and request 2 (50 shares) settled at different exchange rates, the assets owed for redeem(80) depend on which shares you treat as redeemed. Aggregation papers over this by treating the controller’s claimable balance as a single pool with a single effective rate, which I think is the only consistent interpretation, but it’s worth saying explicitly in the spec because implementers will otherwise have to invent FIFO or LIFO conventions on their own.
This thread is part of why I’ve been working on an alternative async-vault representation that uses per-request NFTs instead of aggregated controller balances. The aggregation ambiguity @giorgilagidze is pointing at is one of the things that disappears when each request is a distinct on-chain object: there is no “which 80 of the 100 shares” question because each receipt has its own amount, mint timestamp, and (if applicable) settlement rate.
I’m not posting to suggest 7540 should change. The receipt model is suited to retail flows where the pending position should be wallet-visible and composable as a primitive; 7540 fits programmatic and institutional flows where the aggregation is a feature rather than a problem. The two are complementary.
For anyone interested, the proposal is here:
https://ethereum-magicians.org/t/erc-receipt-nfts-for-asynchronous-erc-4626-vaults/28529
Feedback from the 7540 contributors would be especially valuable since you’ve already lived through the design questions a successor standard would have to answer 