This message shows up when MakeOTF is forced to split a lookup table in two subtables in order to separate conflicting glyph class definitions.
You may remember that in class kerning, all the left side glyphs classes that are applied in a single lookup table must be mutually exclusive; that is, a glyph may not belong to more than one left side class in a single table. Same for right side classes. When you include the same glyph in different classes on the same side in your list of kern class pairs, then MakeOTF can solve the structural limitation only by breaking the lookup table in two, such that the the conflicting classes are used in different sub-tables. However, this solves only the structural problem - you still have a functional problem. In your example, the first kern pair which uses the glyph 't' on the left side will mask any subseqent kern pair that includes the glyph "t" on the same side, as all right-side glyphs NOT paired with the glyph "t" with the first subtable will be assigned kern value of zero, and applications will never proceed to see that there are additonal kern paris with "t" on the left side. This is because for any lookup-table, all the glyphs not included in any class on the left or right side are put in an invisible class, and assigned a value of zero.
What this message should say is " you made an error in building either your left side or right side classes for use in the current lookup table- please fix the class definitions so that they are mutually exclusive."
One way to imagine all this is to imagine the class pairs as a spreadsheet of all possible class pairs. Each left side class is the title of a row, and each right side class is the title of a column. A glyph can be put in only one row title, and in only one column titile. All glyphs not named in a row title get put together in a special row title. All glyphs not named in a column title get put together in a special column title. When you specify the value of a class pair, you are specifiying the value in one cell of the spreadsheet. All cells for which no values are specified are set to 0, by default. When programs look for a kern value between "t" and something else, they look through the list of left side class definitions to find the first occurrence of 't'. By definition, the spreadsheet row for "t" defines the kern pair value of "t" with all other glyphs, and the programs does not look further. As a result, any class kern pairs with "t" on the left side in subseuqent subtables will never get seen.
Using the 'subtable' keyword fixes only the structural problem - MakeOTF can then build the feature as specified - but it is still broken from the point of view of intended function.
I am curious about the secondary problem you mention. When you use the 'subtable' keyword, in what way is the generated code invalid?