You can't have it both ways. You need to find a way to evaluate people and, through that evaluation, grok whether or not they can pick up a new technology that they aren't already familiar with. If you can't figure that out, your interview process has failed. Think about it: the complexity and difficulty of your own problems vastly exceed the difficulty a senior engineer faces learning a few new frameworks or APIs. If not, you're doing something pretty trivial.
The best people I've ever worked with weren't people who a priori understood the technology stack we were working with -- instead, they have been seasoned engineers who know how go out and learn, and then apply what they already know in a new environment. This seems so obvious I feel silly even writing it down here, but this is on the front page, so it must be resonating with folks.
What tptacek has said about .NET developers working at IT departments at huge organizations really rings true here. If you immediately write someone off because they work with technologies you don't work with[1] then you're doing it wrong.
1. Assuming you're not looking for a quick, contracted hired gun for something fairly straightforward.