Caridy Patiño

It is intentional. Basically, what should be the result of `new Component()`? Should that return an element? it can't be, because that's not exactly a custom element constructor. should that...

> I'm not totally convinced this is something we need to support, though. That's why we have `CustomElementConstructor`. Exactly, you don't do `new Component()` instead you do `new Component.CustomElementConstructor()`, and...

Well, with #2724 that's not longer observable... so creating x-foo that was claimed by LWC via a pivot is not visible to user-land code, so for them creating that element...

`element.constructor.toString()` should never be native code if the element is a custom element. I don't understand.

I see! maybe we can make it a class considering that in IE11 that's the case anyways... so we can target the path of patching to use a class instead...

I don't remember all the details about the then/else situation. Maybe @diervo remembers. Few things that come to mind: 1. the compiler doesn't have relationships between nodes beyond parent/child relationship...

well, certainly, the main issue is how to support that component in non-native? is that's not supported, then yes. The idea to restrict it everywhere is to have more confident...

> > I might be missing something here. Are we still pursuing the props option bag mechanism? If the answer is yes, then this change should be no necessary since...

I believe this feature was drop in favor of `lwc:spread` combined with `lwc:dynamic`.

@bathos sins from the past. I think your analysis is correct, and maybe just adding a new test here, and perhaps clarifying a little bit better on 402 will be...