E.g., there's a mode that highlights the current line. And there's a mode that let's you run a shell inside a buffer.
And for some reason, the current line highlight doesn't work on the most-recent (waiting for input) line.
OK, actually looking at this a little more closely, I think it's because shell mode does some sort of thing where it redefines the "start" of the line to not include the shell prompt, and I guess whatever is doing the line highlighting is using that same notion of "start" of line. So on a line that just contains the prompt, the line highlighter thinks the line is zero length, and highlights nothing.
I think this is typical of lots of emacs problems. You have all these modes that interact w/ each other, w/o strong models of the interactions, so you end up with a bunch of little bugs.
(And because there's combinatorially many different ways you can combine modes, I don't think testing is ever really going to help you here. You just need formal structures and coding styles that guarantee or lend themselves more to correctness.)
There's no difference between an advanced emacs config and a software project.
If you don't test or incubate features long enough before your workflow depends on them you'll find yourself building atop more bugs.
I find tagging releases of my emacs config useful for this.