This should be considered fixed, now that patch #2851 is committed.

hm
-Why didn't you go for the wml fix suggested ?
-I think we should not mark things "in progress" unless they're assigned to someone.
-The C++ fix suggested made sense to me and should be feasible. It's a rather important feature though and should be discussed.

Sort of fixed bug #17527 (Feeding ability doubles) WML-side. The fix doesn't work in every imaginable situation though (the exceptions should be very rare), so a proper engine-side fix is still wanted eventually.

(Browse SVN revision 49397)

There's a long-standing flaw in the Feeding ability (effectively described at http://wiki.wesnoth.org/EventWML#A_Trap_for_the_Unwary) that recently got upgraded to a core bug by the introduction of the Ghast. If more than one different unit type with the Feeding ability from core are included in the same scenario, the effective benefits of the ability are multiplied by the number of unit types that are involved.

The simplest fix is to add the unit type to the macro, i.e.:

#define ABILITY_FEEDING TYPE
...
[filter_second]
ability=feeding
type={TYPE}
[/filter_second]

The Ghast and Necrophage would then need to have their {ABILITY_FEEDING} line changed to {ABILITY_FEEDING (Ghast)} and {ABILITY_FEEDING (Necrophage), respectively.

Ideally, this problem should be dealt with by a C++ fix, that is, adding an "id" attribute to the [event] tag that works similarly to the "id" attribute in [object]. This would fix all cases of the "trap," not just the event-in-ability case.