I would hope that in the development stage that this is going to be available in implementations. I'm trying to think why it needs to be defined in the spec. Does it need to be?

Not necessarily. It's just frustrating that none of the deployment features can be adequately defined in the spec (i.e. Groovy, and reloading artifacts). The JSR says:

Eliminate the "deployment step". All the artifacts that comprise a JSF application can be modified while the application is running. This will bring the responsiveness people have been used to with iterative JSP development to the JSF developer. One design idea for this is to allow JSF artifacts to be authored in Script.

As far as I can tell, the only parts of this we've actually covered are (1) reloading of VDL pages, and (2) allowing components to be authored in Script. So, an implementation can only support (1) and (2), and consequently still require restarts for changes to faces-config.xml or other artifacts (such as managed beans). That's not much better than JSF 1.2.

In that case, I think we should just have a general reload flag (or just say that the reload flag is tied to the stage) and have a list of what should be reloadable in the spec. Who the heck wouldn't want Facelets templates to be reloaded in the development stage? There should probably be a universal scan time which has a default value for the development stage and can be specified explicitly if someone wants reloading in the producation stage (for whatever reason). Get rid of the Facelets-specific reload interval.

-Dan