Ok, I'll do comments for each part:
> A decision was made early in this process to strive for backwards compatibility between the latest popular version of Facelets and Facelets in JSF 2.0. The sole determinant to backwards compatibility lies in the answer to the question, "is there any Java code in the application, or in libraries used by the application, that extends from or depends on any class in package com.sun.facelets and/or its sub-packages?"
In other words, it says below are the criteria to define whether an application is compatible with facelets for jsf 2.0. Suppose you have an application/jsf component library working with facelets 1.1.x, so if you want to know if it is compatible or not with facelets for jsf 2.0 you have to ask this question first.
> ■ If the answer to this question is "yes", Facelets in JSF 2.0 is not backwards compatibile with Facelets and such an application must continue to bundle the Facelets jar file along with the application, continue to set the Facelets configuration parameters, and also set the javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
> <context-param> to true. Please see Section 11.1.3 "Application Configuration Parameters" for details on this
> option. Any code that extends or depends on any class in package com.sun.facelets and/or its sub-packages
> must be modified to depend on the appropriate classes in package javax.faces.webapp.vdl and/or its subpackages.
In other words it says if you have classes that uses com.sun.facelets package (read use as you have classes depending from), your application/jsf component library IS NOT compatible with facelets for jsf 2.0, but you can use the old facelets jars and register the old facelets view handler to keep using them as is. The other alternative is modify all clasess that uses com.sun.facelets and/or its sub-packages to the appropiate javax.faces.webapp.vdl counterpart. If you do that your application / jsf component library will work for jsf 2.0. The param is used to tell jsf please use the jsp view handler (JspViewHandlerImpl in myfaces case), because the other one introduced in jsf 2.0 (ViewHandlerImpl) could cause conflicts.
Note that the only reason why an application / jsf component library could have a facelet taglib xml file is to reference classes that extends com.su.facelets package.
> ■ If the answer to this question is "no", Facelets in JSF 2.0 is backwards compatible with pre-JSF 2.0 Facelets and such an application must not continue to bundle the Facelets jar file along with the application, and must not continue to set the Facelets configuration parameters.
If this is true, your application/ jsf component library already works for facelets in JSF 2.0. You can use it directly without make changes, but again that means there is no facelet taglib xml files.
> Thankfully, most applications that use Facelets fall into the latter category, or, if they fall in the former, their dependence will easily be migrated to the new public classes.
My answer is no, we can't reopen this one, but I'll let it open to hear if someone in jsr-314-open list has something to say about it