Approaches to environments

We are using BuildMaster to deploy builds that are created in TFS. We have just started this, and it works fine, although we now need to re-evaluate our approach with environments/releases in BuildMaster. We are expanding this to more applications, and strategies for re-use of deployment plans and action groups becomes an issue. In our model, we have multiple environments within each promotion step, so we do not only have a linear Dev->QA->Stage->Prod promotion model. We have sub-environments within a "promotion level" environment, and we are switching tasks for those sub-environments. While not providing exact details, say we have 5 dev systems named Dev1, Dev2..Dev5, then 5 QA systems called QA1, QA2..QA5, then a couple of staging environments and a prod with many servers. At the moment, I have set this up in BuildMaster so that each environment has their own deployment plan, so I have a Dev1 plan, a Dev2 plan etc. Problem is maintenance and scalability. I experiment with the linked action group concept, and that may be one option, but the problem with that is that I cannot hard-code servers for each environment, but have to use variables. Then select servers at deployment time, which defeats the idea with a predefined environment. Then, I might as well just use one deployment plan for all Dev environments, and select servers per variable at deployment plan. It will be similar to linking action groups. The only other way is to keep one deployment plan for each instance of each environment, but that is a lot of maintenance. Does anyone have ideas for how to handled this, or are there functions and features in BuildMaster that I am missing?

Product: BuildMaster
Version: 4.1.7

This sound like it's just a tough process to model. No matter what you do, you can't have it both ways such that you could deploy to either a subset of DevX servers to an arbitrary subset of QAX servers. The options you'll have to decide on are either:

use different workflows and different environments to separate Dev1 from Dev2, which will force releases to use a specific set of servers after a build is created for it
use abstract environments (Dev, QA) with server variables that resolve to different server groups (e.g. DevSet1, DevSet2, or whatever), and select the result either at release, build, or promotion time so it provides historical context with the release/build

In BuildMaster, the idea of an Environment (i.e. a different stage of testing) is meant to be abstracted from a Server (i.e. a physical/virtual machine), so whatever follows most closely to this paradigm would be the way to go.