Thinking about this a little more, I have a feeling that we are coming
at this from different directions.

If it is the case that a backport has to be a drop in replacement for
what is currently in the  distribution, then backporting Apache2.2
would be totally impractical. It conflicts with a lot of modules which
don't have Feisty replacements - libapache2-mod-python24 and
libapache2-mod-php4 for starters.

If 'complete backward compatible replacement' is the policy for
backports then that precludes movement from anything much more than
the +1 release because as time moves on too much needs to be
recompiled and it becomes a waste of effort. It also means that
backports to LTS releases become less and less likely, so the LTS
wastes away.

The obvious solution to that is to make sure that LTS releases happen
at intervals much less than the  actual support period so that LTS
upgrades can be planned in.  Perhaps somebody would be good enough to
ask the question as to when the next LTS can be expected.

The alternative is to see backports as 'augmentation' - particularly
as with Dapper there is a perfectly good and commercially supported
version of apache2 in the distribution. Unlike Feisty, Dapper has
Apache 2.0 at its disposal. You would only go to 2.2 if you needed its
facilities (the case in point being the mod-proxy-balancer widely used
in Rails houses) and the mods you need have been backported. If not
then you get the job of doing the backport on the bit you require!

If you take the 'augmentation' position then you only require a small
number of modules in the backport. Existing modules will conflict
correctly, and yes it may break Bugzilla - but I would suggest that it
is the job of the people who want to run Bugzilla with 2.2 to do the
backport work required to make that combination work on Dapper, not
me. (It may work flawless out of the box. I don't know.).

There is a set of backported Dapper apache2.2 packages on kodefoo
(http://packages.kodefoo.com/dists/dapper/main/binary-i386/Packages)
that has worked fine all year on commercial services supporting Rails,
php5 and perl. That's a lot of real world testing backing up the port.

The only reason for getting these into dapper-backports is to refocus
the community on a single set of auto-built backport packages, get any
bugs tracked in the right place and generally save a lot of messing
around with apt-keys or compilations. But if it is going to be a lot
of trouble requiring extensive testing of package combinations no
sensible sysadmin is going to use then we're not going to save any
community time going down this route. kodefoo works after all and PPAs
are just around the corner.

So if policy dictates complete backward compatibility then we need to
move to WONTFIX straight away. However if there is room for an
augmentation approach, I would suggest a subset similar to the kodefoo
archive would be the pragmatic way forward - and would limit the work
required on all sides. I doubt that implementing such a small subset
would cause much in the way of bug reports (except possibly by those
who haven't pinned their backports properly), but it would be of great
value to the Rails community. I would ask that the possibility is
given some consideration.