You should order your features so that .smcp is executed before .alt.

For lowercase alternates, the only reason I can imagine needing a duplicate .smcp glyph is if you have some feature coming after smcp that would need to know whether the original glyph was an alternate (i.e. in order to convert it back to lowercase?). But I can't think of any practical examples of such a feature, so probably not necessary.

For uppercase alternates, it might be useful to include real smallcap glyphs that could be invoked with the c2sc feature.

You should order your features so that .smcp is executed before .alt.

Otherwise include both glyphs in the smcp feature (i.e. sub [t t.alt] by T.smcp;).

So I'll leave the alternative smallcap glyphs in the alt feature, not in the smallcaps feature? I'll test this next.

Otherwise include both glyphs in the smcp feature (i.e. sub [T T.alt] by T.smcp;).

I'm not sure where I got this idea, but doesn't it create problems if two different glyphs are substituted with the same target glyph? On related note, should I replace both /dotlessi and /i.TRK (/i basically) with /I.smcp?

…if two different glyphs are substituted with the same target glyph…

Make three identical target glyphs, named differently.
As Justin says, there may be no practical use for that, but if it helps you keep things straight in your head and logically organized, it’s a best practice. Redundancy can also be useful if you ever have someone else work on your files, or return to the files after several years and try to figure out what on earth you were thinking back then!

t.smcp
t.alt.smcp
T.smcp

There was a thread last year with some best practices for naming/coding small caps: a.smcp or A.smcp

See also Adam's advice on /dotlessi and /i.TRK.

I've read that Adam's advice. So basically what Nick said: just make corresponding glyphs for everything. Somehow this fights against my stubborn common sense and I can't believe it, but I guess I have to now. Thanks everybody!

This is crazy. All you need to do is put the smcp feature before your alt features, or really any features that transform upper or lowercase glyphs into something that has no corresponding form in the small caps (e.g., liga). (Only exception would be fi and fl which exist as single type-able glyphs in some encodings.)

True, but that technique requires omitting "t.alt" from @smcp_source, and complicates feature order.
If, for some unrelated reason, one decides to copy and paste the glyphs in that class, or change the feature order, then things could go wrong. This form of glyph proliferation is suggested as a general best practice, containing redundancy but pre-empting complications by removing exceptions.

If I wanted to reuse the lowercase class for something else but also wanted “t.alt” included, rather than add redundant glyphs in the font, I would just do something like this:

sub [ @lowercase t.alt ] by [ @lowercase_foo t.alt.foo ] ;

Or, just make another class, like this:

@lowercase_extended = [ @lowercase t.alt ] ;

There are certainly cases where redundant glyphs make sense, but if it’s to solve a problem that could be solved by changing feature order or adding a class or class exception, I think it’s a bad idea.

But say you decided to make a set of superior letters, if you copied the glyph list from your @smcp_source class you would miss the t.alt.

Right, just make a new class like this:

@sups_source = [ @smcp_source t.alt ] ;

Of course, FontLab doesn’t provide an obvious way to do this when you use the Class panel, but you can add new classes with code like this to the bottom right section of the OpenType panel.

How would you know t.alt was not included in @smcp_source?
Wouldn’t you (or someone else working on the file) assume that @smcp_source contained all the lower case characters?

I would assume by the name that all the glyphs in @smpc_source would only be glyphs that also had corresponding small cap forms. If t.alt didn’t have such a form, I wouldn’t expect it to be included.