Giving scripts the ability to refer to data on the blockchain will reduce transaction sizes because key material does not have to be repeated in every Script.
Given that address reuse is discouraged, and as far as I know is predominantly utilized for customer deposit addresses by exchanges, many of which have not invested resources in batching withdrawals or consolidating small UTXOs, I am skeptical that such a feature would actually be utilized by users for whom a potential use exists, especially as mining fees are usually pushed onto customers anyway.
Unless extensively utilized such that costs outweigh benefits, this change would impose an externality on validating nodes:
With this list a newly created script can refer to a specific PUSHDATA that was used in any previously confirmed block.
This
would make pruning impossible, and also relaxes
the bounds on validation costs since it would allow random reads on
all historical data as opposed to just the UTXO set.
Although it would do nothing for block capacity, perhaps this redundancy might be better addressed as opt-in functionality in the p2p layer? It might help with IBD, though at least in my experience peer latency (as opposed to throughput) is the limiting factor, and as far as I can tell this would increase it. Somewhat relatedly, transaction IDs are another type of pointer which might benefit from being encoded as a (block height, offset). However, here too it seems to me like the complexity is substantial, potentially introducing new DoS vectors, while saving several bytes per input at most.
Regards,
Yuval