Thanks Sam,
While I like the simplicity of approach B - I do not think the DOM manipulation is simple/scalable. Imagine a list with 1000 items - parsing the entire dom of the list to add an attribute to the top level node is wasteful. Neither do I think it can be solved with regexes or any other "quick fix" - I think it's doomed to fail.
I also thing that approach A was too complex. There was a lot of hidden detail in that branch, that I could not follow from reading the code alone.
Freds suggestion does sound good initially - but I agree that if you take that path down the road you will have to overide 20 render methods to change the style of a button consistently.
Really I like the further work you did - and the prototype_3 branch seems the closest to a nice solution I have seen. It is relatively simple, but allows parent containers to put some additional "state" into the renderables it contains. The method for rendering a (e.g.) button is defined only once - but it is flexible enough to cover the different uses.
There are some more fine details to be worked out there, such as the stripping of "core_ui_" prefixes or whether we want to use namespaces such as in https://tracker.moodle.org/browse/MDL-41663 to achieve this. (I don't think I am in favour of stripping the prefixes even if it means long render method names - at least the long names lead to easier finding of the exact method to overwrite - less magic).
So - ATM I give my vote to prototype_3 with a bit more finesse-ing.
There is mention of various prototypes. Where?
I have more to say, but no time. Argh!