This is something I've been interested in.
What you need is a basic merkle sum tree (not sparse), so if e.g. you want to burn 10, 20, 30 and 40 sats for separate use cases, in a single tx you can burn 100 sats and commit to a tree with four leaves, and the merkle proof contains the values. E.g. the rightmost leaf is 40 and has 30 as its neighbor, and moves up to a node of 70 which has 30 (=10+20) as its neighbor, totalling 100.
The leaf hash needs to commit to the intent/recipient of the burn, so that way you can't "double spend" the burn by reusing it for more than one purpose.
You could outsource the burn to an aggregating third party by paying them e.g. over LN but it won't be atomic, so they could walk away with your payment without actually following through with the burn (but presumably take a reputational hit).
As I believe you already realized, while an op_return is needed (or rather, preferred) to burn, you don't necessarily have to put the hash there and can thus save some bytes. One possible place to commit the root hash is in a double taproot commitment in the change output. So while taproot is Q = P + hash(Q||mast)*G, you'd commit the root in P such that P = N + hash(N||burn_tree_root)*G. What's important is that the location is fully deterministic, in order to ensure there isn't more than one tree (which would be yet another way to "double spend").
Finally, you can perform the burn on a spacechain[0] (basically a "sidechain" that has burned BTC as its native token) in order to pretty much avoid using mainchain block space altogether, so it should scale much better. It's worth noting that this fully supports SPV proofs, so the third party you're proving the burn to doesn't have to run a full node (though SPV may not be safe enough for big amounts).
To me this seems like a possible way to revitalize the original hashcash use case, e.g. by only accepting emails which have an SPV proof of some burned sats attached, or any other place where spam is an issue.
Cheers,
Ruben