Add dynamic component capability for list item customization

[Bartheleway]

Is your feature request related to a problem? Please describe.
Let's say we try to implement the SLDS Combobox component in LWC. We will get stuck at some point in customization options because LWC doesn't allow "list composition" (I'm unsure which term to use). So we can't write a generic component that handle all the combobox logic and when used, customize only how we render the options.

Composition allow us to put a component inside another, giving the ability to customize some part of it when implementing.
When it comes to list, LWC doesn't provide any option but to copy paste the entire component and change only the HTML.

Describe the solution you'd like
Any way to give the capability to give at implementation a way to give which component to use as an item in a list component.

This is one try which kind of works but throws an error when changing the items: https://webcomponents.dev/edit/8NKaFZYri3ny7phlYa5q
This also has some limitation like not updating automatically data on the child elements.

Another option was to use lwc:dynamic but it seems that it will never be generally available (https://rfcs.lwc.dev/rfcs/lwc/0110-dynamic-components)

I was also interested by having a similar option as VueJs slot-scope but it got rejected. Too bad because I already worked with VueJs and their approach make it really handy.

Additional context
Documentation says we should use "data" but doesn't provide any information on how to solve this.
The Salesforce documention also indicates that An example of a base component that’s created using the data-driven approach is lightning-datatable. But don't provide source code to let us understand how this works.

I'm happy to help / debate on this ;)

[jonshipmansmc]

Suggestion is to close this issue.

The paradigm is as follows:
props down, events up

The use case would be to track the items as an array of objects where "isEnabled" is inside the looped as an object prop. So suggestedValues in your childItem would become [Object] and not [String]. You could keep it as it's written and change it to a getter and setter.

By destroying a child from within the child's scope you're not gaining anything other than the potential for headaches down the road.

[nolanlawson]

This sounds like it's covered by scoped slots: #2332

Please reopen if I'm wrong about this. Thanks!