a single payment to a single recipient
Lightning wallets assume a single recipient for a single payment. Alice can send money to Bob in a single payment, and Alice can send money to Carol, but Alice cannot send money to both Bob and Carol in a single payment. Alice, or her wallet, must pay each independently and it's possible that Alice's payment to Carol succeeds while Alice's payment to Bob fails. On lightning, coordinating a single payment (ie input) to more than one recipient (ie outputs), where all recipients are paid or none are paid, is left to Alice and Bob and Carol to figure out. Maybe lightning wallets shouldn't coordinate a single payment with more than a single receiver in a trust minimized way, but it'd be useful, and surprisingly so, if they did.
most lightning payments pay multiple recipients
When Alice pays Carol on the lightning network, Alice's money often travels through several other lightning nodes before arriving at Carol's lightning node. The nodes that Alice sends her money through don't do this for free. Alice pays them. What's more, those other lightning nodes only get paid by Alice if Carol gets paid. Those other lightning nodes are effectively Bob(s) from the previous section's example; that is, the other lightning nodes are additional trust-minimized recipients as part of Alice's payment to Carol. Only, those other lightning nodes are secondary to Alice's payment to Carol.
In the lightning protocol as-is, Carol can't make sure Alice's money travels through a specific Bob, and Bob can't enforce that Alice pays Carol through him. If Carol and Bob don't trust each other nor Alice, yet both can agree to receive money from Alice only if the other also gets paid, the lightning protocol as-is can't help them. If Carol and Bob want to enter such a contract, they have to get creative.
trust minimized split payments enable trust minimized coordination
The lightning network coordinates delivery of bitcoin from Alice to Carol by paying several Bobs to move their bitcoin in Carol's direction. By design, Alice, the Bobs, and Carol don't need to trust each other much to do this. Ideally, they wouldn't need to trust each other at all. Less required trust means less required permission and less required permission means more freedom, opportunity, and competition. People want to coordinate and if they can't do so in a trust minimized way, fewer people will coordinate and the coordination that does happen will tend to be centralized.
splitting a payment atomically and downstream is better ux
Imagine swiping your credit card five times when you buy something, once to pay Visa, another to pay the merchant, another to pay the merchant's landlord, another to pay the supplier, and another to pay the manufacturer. Now imagine the payment to the supplier fails and continues to fail, then swiping your card four times to get a refund from everyone you paid. If the complexity of Visa, the merchant, the landlord, etc coordinating with each other is thrust on the customer, the customer will prefer a merchant that doesn't expose the complexity, and such a preferred merchant will have more trusted relationships with the other parties.
That's a toy example, but we do atomic split payments on bitcoin's base layer because it's plain practical. Imagine paying two invoices to your LSP when you want to open a channel. What should they do with your funds when the second payment doesn't arrive? Or how about creating two bitcoin transactions every time you want to pay someone, one to pay the miner and one to pay the receiver?
Atomicity means that when receivers coordinate they don't need to trust each other fully, and if the split happens downstream, the UX for the sender is identical whether there's one receiver or many.
today's hacks are tomorrow's solutions
One way to be certain people want something is that they trip over themselves for solutions that work poorly. When they really want something, they create elaborate, inelegant, risky hacks that give them the faintest whiff of a satisfying solution. Should a better solution exist, you know they'll use it.
hold invoices
Most non-wallet lightning companies (ones that don't have the luxury of going on-chain for atomic split payments) have currently implemented or at least explored using hold invoices for split payments. Geyser does this to non-custodially take a platform fee. Robosats does this to fulfill an order conditional on an escrow agent's approval (their solution is custodial though because they can't be sure the buyer will be online to accept the payment). Mash once explored this. lnproxy does this to hide a receiver's node from senders and proxies get paid to do so. We plan to cautiously do this to take our sybil fee non-custodially.
Using hold invoices this way allows applications to be Bob when their customer Alice pays their customer Carol. It's elaborate, inelegant, and risky, but any other solution is custodial, trusted, or imposes new requirements on the sender and/or receiver. These hold invoices give Alice, Bob, and Carol a way to coordinate a split payment without Bob or Carol taking custody of the other's funds, or trusting that Alice is willing and able to send funds to both of them. It also hides the identity of Carol's lightning node from Alice which is otherwise exposed.
This use of hold invoices recreates how a lightning node forwards a payment, using the familiar preimage and CTLV enforcement, but does so at the application layer. When Alice tells Bob she wants to pay Carol, Bob requests an invoice from Carol. Bob then wraps the invoice, meaning Bob's invoice is conditional on Carol's invoice being paid, and sends it to Alice. Alice then pays Bob's wrapped invoice and because Bob can't redeem Alice's payment without first paying Carol, Bob pays Carol and then claims his funds from Alice. Hence, at no point is Bob in custody of Alice's funds meant for Carol. And, when Bob wraps Carol's invoice, he can add an additional split payment to himself.
many payments to many recipients
The main, in-use alternative to the hold invoice approach is requesting Alice pay each Bob and Carol independently. One popular example of this approach is nostr prisms. Using programmatic wallet connections, an application requests invoices from an arbitrary number of Bobs and Carols, then sends them all to Alice's wallet to pay one by one. Pending adoption of a soon to be merged(?) lnurl spec, Bob might even be able to request proof that Alice paid Carol (assuming Carol isn't in cahoots with Alice to trick Bob).
bolt12 and blinded paths
If I'm not mistaken, Bolt12's blinded paths, when adopted widely, should replace the hold invoice approach. If Bob is provably the introduction point to a blinded path in an amount-less bolt12 offer that pays Carol, then Bob can enforce that he'll be paid when Alice pays Carol. Using this approach, it might be possible for several Bobs to be predictably paid when Carol does, assuming blinded paths can contain other blinded paths. This isn't my exact dream of a single payment being split along independent routes, to different receivers, with codependent settlement at the protocol layer, but maybe novel forms of decentralized coordination can wait for bolt13.