I would suggest actually learning how it works before commenting on it.
Lightning allows users to take a single bitcoin transaction, and use it over a finite space of time, in order to shift bitcoin back and forth, with no or vanishingly small transaction fees, as iou's between what are called 'lightning channels'. The actual transaction size will be the same as a normal transaction, with a flag that says it can only be committed to the blockchain at a specific time (or block depth). In effect, these lightning transactions are cryptographically signed 'iou's. The 'thousands' of back-and-forth iou changes are discarded when the channel is closed (massive privacy dividend), and only the aggregated change is committed to the blockchain. This is the great thing about lightning. It is a single transaction with as many inputs and outputs (one/two) as defined in the original transaction. Only the transaction values change.
Consider a channel link of this : John->Bob->Sally->Anne. Only the people next to each other in the chain have a 'channel open' with each other (John/Bob, Bob/Sally, Sally/Anne). Assuming each of the channels between all of the participants have adequate funds in order to achieve this, if John wanted to send 1btc to Anne. A transaction ledger would read :
John->Bob channel : John -1btc, Bob +1btc
Bob->Sally channel : Bob -1btc, Sally +1btc
Sally->Anne channel : Sally -1btc, Anne +1btc.
Anne now has 1btc more, and John has 1btc less, but the net effect in each channel is simply a modification to the distribution of bitcoin in that channel.
Imagine this happening, back and forth, and extended to thousands, tens of thousands, and millions of people. As long as there's a chain between them, you use the chain. You might even have your transaction split over multiple chains. For links that don't have a chain, you create a channel on-the-fly.
Each channel, therefore, only ends up with the same single input, and the same two outputs, just differing values.
It's significantly more complex than that (transaction routing, and channel closure mechanics), but that's the idea. I wish I could remember the lightning dev that explained it. It really is very clever. I haven't actually questioned about the effect of having channels with multiple inputs (John/Sally) and outputs (Bob/Anne) at inception. Technically, I can't see any reason why this wouldn't be possible. Just a much weirder set of ramifications.
I would suggest that the method for creating ln channels is most likely : Carol wants to pay Bob 0.5btc. She creates a ln channel with 1btc, of which Bob is allocated 0.5btc, and carol is allocated 0.5btc. Bob gets paid 0.5btc that is accessible once confirmed. Carol has 0.5btc that is now accessible once confirmed. That way the ln can be bootstrapped by existing txns.
I'd also suggest that it would be easier to understand if Bob were Bob Inc. The incentive will be for the buyer to reduce txn fees. If Carol uses a store (coffee?) she will want to reduce paying those fees. So she creates a channel with 0.1btc and 0.001 is allocated to Bob Inc. For the coffee she buys today, coffee + txn fee. Ever more? Zippo txn fee. When your channel is almost zero, you buy bitcoin, it is delivered back to you by the rebalancing of that channel. And because it's Bob Inc the path through the channels from a source of bitcoin is reduced, maybe even two hops ( exchangeA/exchangeB -> exchangeB/Bob Inc. -> Bob Inc./Carol).