We discussed this "staging" concept quite a bit internally for EE 6.
In the end we left it out of the platform because it didn't seem to
solve any problem that couldn't already be solved using other existing
mechanisms, at least as it was being proposed at the time.
We found *very* few cases where the behavior of existing APIs would
change based on what "stage" you were in. About the best we came up
with was that some web application errors might want to produce more
useful output when in development stage. But since we specify very
little about what such output should contain, products already have
the flexibility to vary their behavior in this regard.
If the behavior of the platform APIs don't change based on the stage,
what is it used for? Well, applications could change their behavior
based on the stage, but they can already do that using an appropriate
JNDI environment variable of their own choosing; we didn't really need
to specify that.
One idea we did consider was to have different resource settings based
on the stage. You might bind to one database for testing and another
for production, for instance. Since it's already possible for the
deployer to do these different mappings at deployment time, this seemed
like it would only really be useful if you could specify more details
about the resource you were mapping to, as you can with DataSourceDefinition.
Allowing different resource configurations for different stages
required more changes to the deployment descriptors than we were
willing to consider for EE 6. Since we knew that we wanted to consider
major changes to deployment descriptors in the future, this was another
reason to defer defining anything about stages for EE 6.
So, this may be something we want to consider for EE 7, along with other
improvements to resource configuration that may be required to better
support cloud deployment.