It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
Yeah, Shadow DOM was definitely introduced as an immature technology with lots of problems. Nowadays there's also Declarative Shadow DOM[1] which allows you to create Shadow DOMs without JS. It alleviates some of these problems at the cost of introducing a few more of its own. It's like a drunken stumble with two steps forward and one back.
To the point that even the people working on Web Components finally admitted that in 2022: https://w3c.github.io/webcomponents-cg/2022.html
--- start quote ---
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
--- end quote ---