Depending on how much pre-computation you want to do. You can embed all the different possibilities of which participant unilaterally exits as sibling tapleaves where the transaction creates utxos, one where the individual’s share is ejected entirely, and another where the remaining participants share the utxo:
Let’s say you have a set of N parties, P, indexed from [0, N). You would construct N presigned transactions, with two outputs each, one that pays the ejected party their share, the other pays the remaining set their combined share. From there you have a recursively smaller problem, and you can do this all the way to 0. At first this looks like it has factorial complexity since every sequence of unilateral exits would create a different sequence of shared utxo outpoints. With APO or CTV you can cut it down to \sum_{i=2}^{N} nCi = O(N^3) in offchain computation by sharing common scriptPubKeys since ejections commute. On chain, you get O(N) I think.
Regarding accumulators, it seems like the key requirement is that the consensus rules are capable of either computing or verifying the removal operation. Having an operation that could do this is probably a really useful general opcode.
but those frikkin mathists like 1-character variable names too much, often with characters being in a different font being different things, which is crazy, like this is the first thing programmers get taught, do not use single-character variable names, what is wrong with mathists???
It can be useful to do this because sometimes the shape is more important than the name when trying to grapple with the idea. By using single letter variable names it forces you to contend with the structure of the idea directly. Sometimes any name you give it necessarily forces you to look at it through an overly reductive lens. They could also just be dicks and be doing it unnecessarily, though 