I'll try to find your old post, because the characters need to be in ROM of course, and this was the reason I didn't think about it too hard.
The display-list concept wasn't for character-based games. That's a new idea I just had yesterday when the fact came up that Robinett Basic could do "PRINT" and Batari Basic can't.
The display list concept would allow the user to supply a list giving the height and source address for each playfield "row". Instead of having eleven rows of playfield data that are sixteen pixels high, a programmer could have e.g. one that's 16 high, four that are eight high, one that is 80 high, another four that are eight high, and one that's 16 high (e.g. for a tank-blasting game where the players sit at the top and bottom of the screen behind "shields), or one could have a row that's 16 high, followed by nine that are 8 high, followed by one that's 96 high (e.g. for a "Breakout"-style game).
My preferred implementation would probably be to have the display list contain pairs of numbers where the first item in each pair would be the number of double-lines minus one, and the second would be the RAM address where the data should be found. Specifying the RAM address may or may not be worthwhile; it would allow some extra versatility if non-active rows of display data could be duplicated, and it would allow some interesting special effects, but it might also cause confusion. Having a means of specifying ROM addresses as well might be interesting, but would probably complicate things too much to be useful in-kernel.
I haven't looked at your kernel code, but I would think it should be possible to handle display lists if you used a striped playfield, and if you unrolled one level of looping (so that the first line-pair of a display-list item would use special code), meaning the minimum display-list-item size would be two line-pairs. A game like "Man Goes Down" (but without the pretty colored fruits) could be implemented either by having many display lists in ROM and switching between them, or by putting the display list in RAM.
If your kernel is already using four temp locations to hold the current row of playfield data (I would guess that it probably must) the only extra RAM required for display-list support would be two bytes to hold the display-list pointer. If you can spare that space, adding display lists could greatly improve the versatility of what already seems to be a very promising platform.