There are two real sources in Ikeda-san's green box that we are concerned about: Let's call them (14008, 14160) and (14013, 14159).

Here is the behavior we EXPECT:
1) i-band: add (14008, 14160)(i) to the PeakCatalog
2) r-band:

• merge (14009, 14159)-->(14008,14160)(ir).
• throw away (14013, 14159) because it is < 1" from (14008,14160)

3) z-band: merge (14008, 14160)-->(14008,14160)(irz).
4) y-band: merge (14009, 14160)-->(14008,14160)(irzy)
5) g-band: throw away (14013,14159) because it it < 1" from (14008,14160)

Therefore, we expect just (14008,14160)(irzy) to be in the catalog.

The bug:
actual step 5) g-band:

• add (14013,14159) into a bigger/different overlapping footprint.
• Throw away (14008,14160)(irzy) because it is < 1" from (14013,14159)(g)!
  And only (14013,14159)(g) is in the catalog. It only has one band, and gets culled, leaving us with zero.

Thank you! I agree with the expected behavior, and the current step 5) is doing something bad.

Attaching the before and after for this patch (based on the S18A input detection catalogs)

mergeDet-9813-3,3.fits

mergeDet-9813-3,3-DM-17431.fits

Of  35471 total peaks, 372 are new and 173 peaks were the old that aren't in the new.

Green + are new, red X are not in new (when they were in old). Red X's are peaks from the low-priority band which are now superseded by the neighboring peak in a high priority band.  This behavior is expected and welcome. 

Jim Bosch, would you review? PR in afw: https://github.com/lsst/afw/pull/451

https://ci.lsst.codes/job/stack-os-matrix/29660/

I went for the minimal lines of code change. It'd be more readable IMO if I made _addSpans public or moved the doMerge check out of each if/else in the loop. 

Merged. Thanks for the review Jim.