Actually, it sounds like you know too much for your own good! JSF was designed to be as simple as possible (and no simpler). I'd say the #1 mistake that most people make in getting used to JSF is that instead of using basic Java POJO techniques, they start latching onto every javax.faces class and method in sight, when in fact, in most cases, the only javax.faces stuff that
you should be coding is datamodels and rare references to the FacesContext for things like HTTP information (which I normally confine to a common utility class).
Well, actually, that's the #2 mistake. The #1 mistake they make is in thinking that they can design and implement reliable do-it-yourself security systems,

This has been a bad week for computer security, as you can see from the news.
I don't think it helps that a lot of old and out-of-date stuff on JSF seems to come up ahead of newer and more appropriate info when one does a web search on JSF. JSF went through more than a normal amount of mutations as it was developed, and a lot of the original stuff was really cumbersome. Much of it lives on, since it's still useful, but there are better, cleaner ways.
It sounds like you're trying to pick apart the JSF controls and that's something that after about 5 years or so now, I still rarely (if ever) do. Mostly I stick to the KISS approach where I code a control, bind it with a "value=" attribute and let it be. Cascading dropdown lists and stuff like that I use valueChangeListeners for in order to get the cascade effect. And in a few extreme cases, I'll define an anchor node and dynamically add items underneath it. But only if I can't do it any simpler way.
Do
not use internal definitions to figure out what attributes a JSF tag can use. That's playing with fire. The tag javadocs are authoritative. Anything you find that aren't in the javadoc list of available attributes isn't "real" and may disappear or change radically in future JSF versions. As I said, code "to spec", not "to implementation". Implementations are supposed to be "black boxes", so they can change radically internally as needed. For example, you can't be assured that what's an enum in JSF 1 didn't turn into a Map in JSF 2. It's there for the internal support, not as a definitive resource for applications work. If it were otherwise, it would have been listed in the public JavaDocs (and in the actual JEE spec document itself).
When you dynamically modify the JSF View structure, you instantiate elements such as the HtmlOutputText object. You set its properties using set/get methods, not the enums. In fact, if you
did attempt to use the enums or the setAttribute method directly, you might end up with a defective object, depending on what side effects the object's mutator methods might have. So once again, Keep It Simple: