I also find myself re-using 'Environment's such as Testing, Staging and Production for multiple projects. We use these are standard terms for the environments used in various stages of our build process.

The problem is that some machine roles end up conflicting, so we end up having to create 'project' specific roles... e.g. clientXXX-web or clientXXX-db. However, this kind of defeats the purpose having conceptual roles in your build process... e.g. The concept of 'deploy website to web role', which is 'agnostic' of project or environment, becomes 'deploy website to clientXXX-web'.

A staging server which has IIS and Sql-Server or on it, no longer neatly has roles 'web' and 'db', illustrating is capabilities, but is now 'clientXXX-web, clientYYY-web, clientZZZ-web, clientXXX-db, clientYYY-db, clientZZZ-db', having to create new roles for each project.

if we create project-specific environments, then all of a sudden our build process can't rely on the concepts of 'Testing, Staging, Production' anymore, and has to use the terms 'ClientXXX-Testing, ClientXXX-Staging, ClientXXX-Produciton', which has to be changed in each project.

All of this could be avoided if a project could specify which machines it wanted to use in which roles in each environment.