graphics/jpeg Vs graphics/libjpeg-turbo

[david.sainty%dtsp.co.nz@localhost]

graphics/libjpeg-turbo is a drop-in replacement for graphics/jpeg,
with the difference that it is significantly faster (claiming 2-4x)
than graphics/jpeg on Intel-like platforms through using MMX, SSE and
SSE2 SIMD instructions.

Because it's drop-in compatible, it conflicts with graphics/jpeg.  You
can currently use it by editing graphics/jpeg/buildlink3.mk to pull in
graphics/libjpeg-turbo/buildlink3.mk instead, and everything just
works.  However, it really needs a more convenient solution -
obviously.

One typical solution is something like a mk/jpeg.mk file.  I count at
least 189 .include "../../graphics/jpeg/buildlink3.mk" lines that
would need to be edited.

Another solution is in packages like x11/libX11 which do support
automatically pulling in the non-modular alternatives.

A further solution might be to move graphics/jpeg into
graphics/libjpeg, and use graphics/jpeg as a wrapper package that
pulls in the preferred package.  That'd save editing all the current
users of the jpeg library.  The "alternatives" system looks like it
was going this route (but also seems to be a neglected project?)

Anyone care to suggest which is the right way?