To clarify what I was looking for here a bit, I'm not absolutely sure there is a lot of opportunity for a ton of code reuse. I'm just aware that CoaddPsf and CoaddBoundedField do some very similar things, and it'd be worthwhile to look at the implementations and see what they have in common. In particular:

• Both objects need to store a table of CCDs that went into a coadd, each with weights, a Wcs, and the auxiliary object(s) they need to combine.
• Both objects need to be able look up which coadds contribute to a given point in coadd pixel coordinates.
• Both objects need to persist that table of CCDs.
  I think it's also quite possible we'll have other objects in the future that follow a similar pattern, so it might be nice to have some shared utility classes to make writing such objects easier.

My recollection is that CoaddPsf uses an internal ExposureCatalog to do most of these things, while CoaddBoundedField uses a vector of structs. I don't quite remember why I didn't just use an ExposureCatalog for CoaddBoundedField originally; I think I may have been a little disappointed by how much of CoaddPsf's functionality it didn't provide, but I think it was just mostly that I was in a hurry and I didn't want to figure out how to work it into a slightly different class, especially if that might have required small changes to ExposureCatalog.

See discussion on discourse: https://community.lsst.org/t/discussion-about-unifying-coaddpsf-and-coaddboundedfield-dm-834/293

The conclusion is that there are no alternatives to the current code design that seem sufficiently attractive to justify the effort.