Okay, we have some more information on this.  

The cause seems to be due to the change that Ricahrd and I implemented to comply with the LCD driver chip's errata (https://svn.slimdevices.com/repos/player/trunk/hardware/babyboom/docs/datasheets/display/Novatech%20Errata%20NT39116%20Abnormal%20Display%20Issue%20RGB%20Interface_090117.pdf).

The problem is that the Novatech proposed fix does not work, because it forces the data to change on the falling clock edge, which reduces setup time to almost nothing. I measured 3-5 ns setup time, whereas the spec is 15ns.

I was able to "fix" the issue by setting the LCDC data slew rate to fast, and the LCDC clock to slow.  This gives enough skew to allow the chip to function properly.  

We'll check with Wintek to see if there are any other fixes possible.  In the meantime, we can resolve this in a couple of ways:

Set the drive settings as in my 'fix'.  This is not likely to be a robust solution, as the setup time is too short.
Use SLCDC mode.  This reuquires that we actually get the driver from Freescale, which requires I (or maurice) spend a little time with Galib.  And that the hardware works for this mode, which has not been tested.
Perhaps we can give up the first and last lines of the display, and just use it as a 320x238 display.  This would allow us (I think) to set the data and clock such that the setup time is guaranteed.  But the whole display may move up or down a pixel.  This option needs to be investigated.
For the moment, I'll send Richard a patch that does the quick-and-dirty workaround that seems to make the problem go away.