In a distributed system with multiple permanent build nodes, I would like a scheduling strategy option that favours the fastest available node so that I can get the build and test results sooner. 

This could be based on simple cpu or disk bencharks, or based on previous build times, or both.  A custom distributed testing system we created uses a simple hashes/second metric to select the fastest agent for tests to run on. TeamCity has some performance score for agent selection, although I'm not sure how it's calculated.

One simple use case is where a new node is introduced to an on-premisis build system, and the old nodes are kept for spare capacity.  With the current strategy, builds are still performed on the old node.

Our use case involves many nodes, both fast and slow, with mutiple labels for environment/tools/production etc. and nodes servicing several labels, and we often find builds on slow nodes when fast ones that match the labels are sitting idle.