Note: If ledger transaction scalability is important to you, go upvote 
this initiative on the Developer Feedback Board at https://dx.internetcomputer.org/topic/225
Goal
Add batching endpoint support to ledgers in order to support transaction rate spikes, and overall increases in ledger transaction throughput.
The Problem
Currently, developers can only send a single transaction at a time to ICRC ledgers such as the ICP ledger. This means that canisters which interact with these ledgers are limited to 500 concurrent calls to the ledger at a time.
Source - Canister Output Message Queue Limits, and IC Management Canister Throttling Limits - #2 by paulyoung
This problem applies not only to transferring tokens, but compounds for ICRC2 enabled ledgers. The approve/transfer from paradigm lends itself well to processing subscription payments, which generally is performed in batch.
Additional ledgers can also benefit from batching. For example, the new cycles ledger adds a withdraw cycles functionality to transfer cycles from an account on that ledger to a canister principal.
Additional concerns:
Every outgoing request and outstanding call context requires a memory reservation, which is one of the reasons that the Scalable Messaging Model is being implemented. Providing a batch endpoint on a ledger reduces the number of outstanding calls at a single time (i.e. alternatively making parallel requests to the cycles ledger), which frees up this memory and increases the scalability of the subnet.
Proposed solution:
Add a new batching ICRC standard that allows the caller to send an array of transactions with a single request. The ledger should execute transactions in the same order as they are present in the array, and an array of transaction result types are returned to the caller in the same order as the arguments in the request (some transactions can succeed, and others can fail).
Allow each ledger to determine and expose a limit on the transaction batch size via a icrcX_get_batch_size endpoint. Then, each ledger can adjust this according to the size of the transaction arguments, object, and other scalability concerns.
Extensions
Please apply same batch endpoint enhancements to approve, transfer_from, and withdraw in the Cycles Ledger!