What's really needed are hardware abstractions.
Rather than testing if a specific board is in use, if your sketch (or library) depends on analog input 7, you really need a macro that can test if analog 7 exists. Instead of restricting yourself to only a single board which is known to have analog 7, you code would then be compatible with all boards, current and future, which return something useful for analogRead(7).
For example, Firmata has a symbol called TOTAL_ANALOG_PINS, and in Firmata.h there are many #ifdef checks that attempt to define this for all known boards based on CPU type. Forthcoming versions of Firmata (which are available now in a branch within the Firmata svn) have a Boards.h hardware abstraction layer that offers more capabilities, but it's only available to Firmata.
For hardware abstraction symbols to be truly useful for everyone, they need to become part of the core, with "standard" names. As new boards are created, code which uses the hardware abstraction symbols will automatically work. Perhaps more types of abstractions will be needed over time, as completely envisioning all possible abstractions is nearly impossible. But certainly a lot that is commonly needed, like knowing if an analog pin exists, which (if any) digital pin it's shares, which digital pins share analog features, and how many of each exist are pretty easy.
I've been promoting the hardware abstraction idea, without much success, for about 1 year, around the time the Arduino Mega was released. In issue #59 I've posted some simple but very useful symbols.http://code.google.com/p/arduino/issues/detail?id=59
More are appearing in Firmata, NewSoftSerial, GLCD, and as more libraries try to work on all boards, the need for hardware abstractions will only grow. It's certainly time to standardize on names and start including this stuff in the cores, so as more boards are developed, both by 3rd parties and the Arduino Team, library authors and people who publish widely used examples can start using this stuff.
Long term, rather then locking code to a single board, ways to make such code compatible with all other boards, including those not yet developed, will be a much, much nicer solution.