I agree (mostly) with this plan, I think Richfaces will be a great opportunity to enhance Richfaces without worrying to much about breaking backwards compatibility.
removing internal CSS values and using the cascading part of CSS and avoiding the rendering of default attributes values to greatly reduce the size of the generated HTML. I think that is a change that would be great to have in a Richfaces 3.x and in a much shorter time-frame perhaps in a month? of course, since I am no expert in JSF/Richfaces internal code base I could be underestimating the effort...
Another reason to propose this is that I think that maybe other Richfaces users would appreciate more an improvement in the HTML generated than an integration with JSF 2.0, yes JSF 2.0 is a great an exciting technology, but there are a lot of systems right here and right now that require this optimizations and I bet that many of them will not be easy to migrate to JSF 2.0 but could benefit from a more sensible use of CSS and default attribute values, both modifications that IMHO could be implemented in a way that would a minimal impact in backwards compatibility.
So, what do you think? is it doable?
Your timing is very good - we are planning for 3.3.2, and will see where these fit in. You have probably seen that we have weekly public meetings were we discuss items like this.
I believe there are some jira issues already for this type of update, but please do a quick search and add new jira's with your ideas. Then post back here ;-)
The 3.3.2 release will be a very limited release focusing only on major stability, performance, and bug fixes. This is mainly because we will be focused on 4.0. However some of these overlap items ( like the optimization you mention) could be addressed as well.
Obviously we do need to be more concerned with backwards compatibility with micro releases like this. Please post any suggestions you may have, or create jiras - with good descriptions ;-)