disclaimer: I do not understand the complexities of how browsers implement UI stuff and therefore how hard it is to implement a solution and the scope of my thinking about this issue is limited by this.
Over on the w3c webapps mailing list there has been discussion about 'minimum viable custom elements. One of the current features in the custom elements spec is the ability to subclass elements using is="". This is not liked by some implementers and looks like it will go away. The benefit of being able to subclass is that it allows developers to re-use the features built in to existing elements. This is useful from an accessibility perspective as it does not involve having developers re-implement the accessibility stuff already built-in. A downside to is= is that it does not resolve the issue of being able to decorate native elements as desired, so developers are very likely to continue to eschew subclassing in favour of remaking.
I think if we could provide a relatively simple and attractive method to allow the use of native HTML controls to provide the ‘engines’ for custom elements, it could be of great benefit.
I created a simple (visually crude) example of what i mean using <canvas>. I am not putting this forward as a possible solution, but it does for me, illustrate the benefits of being able to use a native control without concern for the limitations of its visual display.
I don’t know if a solution should be provided in via CSS (appearance for example) or HTML, but I do think that the solution should be relatively simple to use (for web devs) and relatively simple to implement (for browser devs). We should be speccing and implementing reasons for web developers to use native controls not speccing and implementing reasons for not.