Just delete them.
The values for those kern pairs will be replaced by class kerning values.

If they persist, then you know that there are conflicts, with a glyph appearing in more than one class.

For instance, you may have a class for (V' W), and another for (T' Y), but at some point have the bright idea that Y is quite similar to V and W, and decide to put it in that class, for (V' W Y)

So if VA is kerned -80, and TA is kerned -100, then Y will be embarrassed, not knowing exactly how intimate it should be with A.

I wouldn't expand the kerning. The red values are, as you said, exceptions to the class rules, and if you meant them to be exceptions, it's fine to leave them there. If you've made exceptions by accident (by kerning in class kerning with exceptions mode instead of just class kerning mode) just go through and delete the red kern pairs. Exceptions are useful - for example, the /i/ class will probably contain all i diacritic glyphs, and the vast majority of the time they'll kern the same as i, but for certain situations different kerning is needed. It's easier to control these as exceptions rather than have a specific idiacritic kerning class.

Thanks both. So if I undertand you correctly there is no harm in having class exceptions. Baring filesize in mind though (especially considering webfonts) it seems better to compress kerning. Is there a risk of losing kern pairs there, or does fontlab do the job as it should?

Ohh, and btw: This might be a stupid question, but what's the use of the apostrophe after the first glyph of a class (as in nick shinn's example)? The classes seem to work fine without it...

That indicates the key glyph.
It can be in any position the class.

That's what I assumed. Without an apostrophe, though, fontlab just takes the first glyph in the row as the key glyph, which works fine for me.