I agree with the statement that nothing beats application level trapping. I've tested autotrappers with my doozie files multiple times. The auto software works very quickly but nearly evertime something is just not quite right or indeed it is totally wrong.
Since I am considered by many to be a dinosaur STS, my fav of all time was Contex RipnStrip, a LW/CT dual raster compositor and trapper that allowed hand editing during and after the code was read. We ran it on an SGI Unix box with quad processing. The LW file would create the traps in seconds while the composite CT (inc CT spread) would take about three minutes for a tabloid size page once the finished LW was ready. And it could handle up to twelve colors! The beauty of RipnStrip was when language changes had to be made, we'd just merge the alternates with the common materials and produce multiple final versions in a few seconds. We used to have three operators produce the same work in the same time as fifteen guys on the Mac. Alas, all that is gone now. Once Contex was sold, IMO, the newer merged system was too complicated. My point however, is that trapping was object or zone controlled at all times so you could spread or choke differently within the same file at any point up until output including hand drawing a repair of an area. Today's auto trappers follow setting parameters that treat everything the same, ie an object either spreads or chokes period. For packaging work with many spot colors, this never works properly.
John W