There is at least one important use case, though I think the solution is going to be obvious when I say it. Ken Paulsen stated a best practice on the JSF mailing list that I recommend as well, "that all EL should be given the opportunity to be specified explicitly". Meaning you would use #{requestScope.results} instead of just #{results}. In my research for the article on JSF performance I found this to have a measurable impact on performance. But clearly, that is something that should be provided by an EL resolver. (Naturally, most scopes are already supported, so we just need to add the ones that the JSF EL resolver doesn't know about, namely conversationScope). So in the end, not a use case.

The second use case would be to pick off flags that libraries set into scopes. So the values are already there, you just need to read them. Those libraries aren't based on 299 (let's say) and they are sticking stuff into these attribute maps that you need to read. On the flip side, you may need to set attributes that those other libraries rely on. Let's say I am integrating with a system developed a year or two ago (unfair to call it legacy). I have to set some values in the session scope attribute map or else it won't function...such as the current customer id, whether they have accepted a disclaimer, the current user's login name, or whatever. That library is going to go looking in the session map directly, so I can't just make a producer.

The question becomes, how often does this second use case come up? I'll call it read and write "flags" that libraries rely on. People that are dealing with a lot of existing systems are going to have a lot of those cases. Those that get to start anew won't have any. That's my use case, take it or leave it.

-Dan