It's untested due to lack of exporters.
As you say, it's impossible to have interlace and at the same time change "the same interlaced pixel" with only two copperlists. Some general info which I'm sure you know already and then some blurb how it might work.
Without two copperlists, actually an interlaced picture is forced to use the same 12-bit palette for two pixel lines. The first thing that two copperlists would do is cause less 12-bit color errors. This should work fine on all CRTs, deinterlaces such as WinUAE and flickerfixers.
On CRTs, because the raster beam is a fixed width of one lores pixel height, pixel line pairs would overlap by 50 percent and fade into each other. Also, pixels would melt into each other a bit as for lores, generally giving a more pleasant and forgiving picture, or simply a better picture. Not counting the flickering, obviously. But some flicker can be removed by running the exporter a bunch of times with slightly different settings and pre-processing of the picture to begin with (i.e. following the crap in crap out rule). (Normally such pre-processing can be things like blur, dither, avoiding adjacent dark/light swaths or patterns, selecting suitable motives, or using overcontrast/oversaturation or otherwise create blowouts. Generally Photoshop the shit out of it.
This is typically what is done for f.ex. faces, like the one in OP.
15-bit is time dither. Swaths of the same color will hit the in-between color, and gradients too, they will be smoother. Edge pixels between such areas and generally chaotic areas and rapid adjacent color changes will not hit the in between color if the picture is full-res vertically in those areas. An exporter would have to identify those areas and apply a dither pattern to them, i.e. change the bitmap to look perceptually correct. As I see it, any dither would have to be applied together with this. Applying it beforehand would kill the concept. This is what should be solved if you don't want to go 12.5 Hz, two interlaced pictures, and 4 copperlists. But the swaths in between those edges would look good on all displays.
Obviously a HAM exporter specifically will already calculate different bitmaps between each field as it is, partly due to the original picture contents, but also adjust/not follow contents when mapping to get more than 15 colors out. Modify above means modify the calculation.
Maybe you could start with non-HAM modes and go from there, I don't know. But as I said, it's untested.