fallout from recent devel/gettext-lib 0.18.1.1 update

I'm running Darwin 10.7 32-bit (Mac OS X 10.6.7 with Xcode 3.2.6). I
upgraded gettext-lib from 0.14.6 to 0.18.1.1 using pkg_rolling-replace.
libintl from 0.18.1.1 has a different soname, and this caused a few
problems:

* textproc/libxslt and security/libgcrypt link against libintl, but
they don't directly depend on devel/gettext-lib. (I think they build
successfully because they depend on something that depends on
devel/gettext-lib.) I believe this prevented pkg_rolling-replace from
adding them to UNSAFE_TODO, so they were never rebuilt.

* devel/flex and devel/bison both depend on gettext-lib, and
pkg_rolling-replace correctly added them to UNSAFE_TODO, but other
packages in MISMATCH_TODO and UNSAFE_TODO that use flex and/or bison at
build time were somehow tsorted first. Perhaps those other packages
don't directly depend on flex/bison despite directly using them? (I
didn't write down the names of the problematic packages, but I think
security/mit-krb5 was one of them.)

* On Mac OS X, /usr/include/X11/Xlocale.h and /usr/include/xlocale.h
(both supplied by Apple) use the same '#ifndef _XLOCALE_H_' include
guard. libintl.h (from gettext-lib 0.18.1.1) #includes xlocale.h, and
a file in devel/m17n-lib #includes both X11/Xlocale.h and libintl.h, so
both X11/Xlocale.h and xlocale.h get included at the same time. Due to
the colliding include guards, the build fails. This is an X bug that
was fixed in X.org upstream [1] (by an Apple employee) but the fix
hasn't yet made it down to Mac OS X.

My questions for you:
* Is pkg_rolling-replace not the right way to upgrade gettext-lib?

* Is there an easy way to find all packages that link against libintl
but don't directly depend on devel/gettext-lib so that the dependencies
can be fixed? (Is adding a dependency on devel/gettext-lib the correct
fix?)
* Is there an easy way to find all packages that use flex or bison
during build but don't directly depend on them?
* Is there an easy way to prevent a package from linking against a
library if it doesn't directly depend on the package providing that library?
* Is it possible for pkgsrc to work around the _XLOCALE_H_ include
guard bug?