we haven't had an RFC yet that undoes the result of a previous one... I wonder if we should create a new discarded folder for that

It's even trickier than that, because it's not undoing the whole RFC, is undoing one of the alterations proposed by the RFC heheheh

Would amending the original RFC and keeping one source of truth make sense? Unsure what the best way forward here is.

Honestly, I kind of have this feeling that we're going to end up with a sea of RFC's and eventually some of them will end up conflicting somewhere.

I'd propose to go for the idea of having RFC's as a temporary thing and then having a more robust documentation that can be changed based on the proposals that come from the RFCs

This is definitely something to be discussed!

Also thought about that. RFCs could be considered one-shot proposals only and we should port that into doc friendly format, with only how the user should do X

Could you clarify this about root not being in the properties interface? It looks like root is in the Slots type in the example below. Is there some magic happening in the ComponentProps<Slots> helper to remove root?

Or, if root is a prop, what happens if I write:

<Component id="foo" root={{ id: "bar" }} />

Yes, it's ComponentProps responsibility to remove root from Slots and flatten it in Props itself.

Or, if root is a prop, what happens if I write:

<Component id="foo" root={{ id: "bar" }} />

You can't do that, since root is not available as a property

If 'as' is added per-slot, then is components a duplicate way of specifying the component type? E.g. are these two the same thing?

<Component label={{ as: 'span', children: 'foo' }} />
<Component components={{ label: 'span' }} label="foo" /> 

I've been thinking about an alternative that would allow an optional tuple of [component, shorthandProps] for a slot, instead of the components prop. E.g., the equivalent to above would be:

<Component label={[ 'span', 'foo' ]} />

The benefit being that it still supports forwarding the as prop to a custom component:

<Component label={[ MyLabelWithAsProp, { as: 'span', children: 'foo' } ]} />

I wonder if that would be a possible alternative to supporting as natively in all slots?

That would conflict with possible future RFC ideas like the one proposed by @smhigley #19266

If 'as' is added per-slot, then is components a duplicate way of specifying the component type? E.g. are these two the same thing?

<Component label={{ as: 'span', children: 'foo' }} />
<Component components={{ label: 'span' }} label="foo" /> 

well, it would be... but components is also not available in the properties, it's state only

It's also good to make it clear the main difference between as and component is what they support. as is limited to be a mechanism for semantic elements (change button to div), while component doesn't have that limitation, and that's the main reason why as is explicit and components isn't. The repercussion of making components somehow so accessible by the user would lean towards some undesired unmapped behaviors

That would conflict with possible future RFC ideas like the one proposed by @smhigley #19266

My idea was actually an attempt to solve a problem in that RFC--that you couldn't specify a different component per-slot--and would end up working nicely with her proposal. That said, Shift had some detailed comments on her RFC that might change the direction there (and obviate the problem I was trying to solve).

well, it would be... but components is also not available in the properties, it's state only

Ah, I misunderstood from #18642 -- I thought components was being exposed as a prop. Thanks for clarifying 👍