A simple reason for the sensors being the same is the lower cost ones failed final test in some way that made them no longer usable at the full resolution. Like stuck pixels in the outer section, very hot or very cold pixels in the image that will be out of the calibration range at full resolution but will be fine when averaged with neighbours, or dead rows or columns in the outer areas. Averaging 4 pixels to make the lower resolution unit or 16 to make the very low res unit makes sense to use an otherwise wasted chip, bonding, 2 die stack and package that has been up till final test a functional unit electrically but a poor thermal performer.
or, you know, the even simpler reason of "making lots of one kind of chip and changing some settings is a lot cheaper and easier than making four kinds of chip"
I think you are right. It would be very hard, I would think, to manage supply if you were using QC-failed chips in lower end units. You will almost inevitably have too many failed chips, or too few. For a company like Intel who sells their chips to other vendors, this isn't a big deal, as if you have too many, you offer them at a sale price, and if you have too few, the price goes up. Vendors using Intel chips also have a lot of alternatives to choose from. But whereas FLIR uses the chips themselves, they don't really have those options. So I tend to think they just use the exact same chip and I bet most if not all pass the "full" QC check just fine.
I suppose it depends on the number and nature of the typical faults that come out of the process. A lot of random bad pixels would be hard to deal with, but Mapping out the odd few bad pixels from a 320x240 when downscaling to 80x60 could probably be done automatically by looking for differences from neighbours.
If this is done, then some simple production criteria for numbers of bad pixels and minimum distance between them could be used for selection. Considering the big price difference between models,
If they have significant numbers of only-just-bad die it would probably be worth using them.
From what I've seen so far there is not enough NV memory to store a full bad pixel map. I doubt it would be in main flash as all other production data (including sensor serial no) is in the eeprom.
As & when I get time to look at the raw data it should be fairly obvious. It will also be interesting to see what the output looks like before flat-field correction