I don't quite understand this for loop here because we only pass a single refund type each time.

If one wants to build a refund transaction that has multiple type of refunds within a single transaction. I could pass something like refund_types = {STORAGE_CLEAR, AUTHORIZATION_EXISTING_AUTHORITY} to have both refund types in a single transaction. (or any combination of refund types once there are more than just those 2)

Perhaps all of this logic could sandwich the match-case logic like so:

authorization_list = None
refund_counter = 0
match refund_type:
    case RefundTypes.STORAGE_CLEAR:
        for slot in storage_slots:
            code += Op.SSTORE(
                slot,
                Op.PUSH0,
                # Gas accounting
                original_value=1,
                new_value=0,
            )
        empty_storage_on_success = True

    case RefundTypes.AUTHORIZATION_EXISTING_AUTHORITY:
        code += Op.PUSH0
        authorization_list = [
            AuthorizationTuple(
                address=contract_address,
                nonce=0,
                signer=pre.fund_eoa(amount=1),
            )
            for _ in range(refunds_count)
        ]
        refund_counter += gsc.R_AUTHORIZATION_EXISTING_AUTHORITY * refunds_count

    case _:
        raise ValueError(
            f"Unknown refund type: {refund_type} (Test needs update)"
        )
if not refund_tx_reverts:
  refund_counter += code.refund(fork)

Just to not have side-effects disjointed from the code that produces them I think.

Ah. You are right. I went with this approach because we won't have the delegated_contract for creating the auth_tuples until we have the full code and have pre_deployed the contract with that code.

However, as I think more about this, the delegated contract does not necessarily have to be the same as the contract called by the transaction. So I can just deploy a dummy delegated contract and use that for the auth tuples. I have updated with this approach