I have previously given advice on this list about the use of the "subtable" keyword which could lead to kern pairs being unavailable. If you have used this keyword, please review the following.
Class pairs in a kern feature are compiled as a lookup with a single subtable. The representation of the class pairs for a subtable looks like a big Excel spreadsheet, with all the left side pairs as the titles of the rows, and all the right-side pairs as the titles of the columns, and the kern pair values in the fields. As a result, every left side pair you name is kerned against every right side pair you name. Obviously, most of the fields are 0; there are non-zero values only where you specified a class pair kern value. Less obviously, all glyphs not named in a right side class are automatically assigned to right side class 0. This means that every left side class in the subtable is kerned against every glyph in the font ( with most of the kern values being 0).
If you have a lot of left and right side class pairs, this subtable can get so large some of the offset values in the compiled lookup exceed the limit of 64K, and the lookup can't be built. The 'subtable' keyword is provided to help with this problem. It forces the class pair lookup to start a new subtable at the point where you put the 'subtable' keyword. If you have any degree of order in your class kern pair definitions, each of the subtables will then have fewer left and right classes, and the overall size of the lookup is smaller.
My advice on using this keyword is:
a) use it only if you have to because of a size oveflow problem, and
b) there is not much use in trying to be smart about where you put it; it is usually simplest to put the first keyword more or less in the middle of the list of the class kern pairs. If this does not shrink the kern lookup enough, then put another 'subtable' keyword in the middle of each half of the class kern pair list, and so on.
However, I omitted an important warning:
c) any left side class can be used only within a single subtable.
This is because each left side class in a subtable is by definition kerned against every right side class, and hence every glyph in the font because of class 0. It follows that a program looking for a kern pair will never look past the first subtable with a left side class containing the left side glyph. Moral: any left side class can be used only within a single subtable. If you put kern class pairs with that left side class in a subsequent subtable ( e.g; after a subtable break), those kern class pairs will never be seen by any program.
My thanks to Karsten Luecke, whose struggle with an exanple of this problem showed that my previous advice on this list was incomplete.