Something that crystallized in the process of writing the earlier Bourne shell quoting entry is that #ifdef abuse leads to bad results for the same fundamental reason that multiple levels of escaping are bad: after a certain point, people can no longer clearly see what the real code will look like.

When you can't see what the code looks like, it's really hard to make sensible changes; either you make blind stabs or you have to carefully reconstruct the actual code, usually by hand. Either process is error prone, and it's easy to fool yourself, and you are effectively doing remote control programming (with mushy feedback).

Ironically I suspect that the really dangerous #ifdef'd code is not the code that is completely snarled up, but the code that is halfway there. Code that is a complete mess is clearly beyond understanding, but code that is only half-overgrown with #ifdefs tempts you into thinking that you can follow it when you actually can't.

(The worst #ifdef'd code that I've personally encountered and haven't frantically scrubbed out of my brain is the xterm code, which is a shining example of what not to do to make a portable program.)