I think the Stylistic Sets features would be entirely appropriate for something like ’a petite lowercase’. This is exactly the sort of thing the features were designed for.

I think using them for something like specially tailored superiors for e.g. footnotes as opposed to ordinals, would also be appropriate and not at all a hack, so long as you implement the features so that the stylistic set feature is used in conjunction with the superiors feature. So you wouldn’t use e.g. ’ss01’ to map regular numerals to your special superior numerals, you would use it to map the superior numerals resulting from the ’sups’ feature to those special, stylistic forms. This is entirely legitimate, because what you are doing is applying stylistic variants of superior letters.

Cross-font compatibility is always going to be a problem for anything involving stylistic substitutions, and there is no way around this. Ideally, applications should have the option to automatically turn off stylistic set layout tags when you switch fonts out of a particular family.

I can’t think of a case where “ss01”-“ss20” could be hacked. These features are intended to be “non-semantic” i.e. they do not impose a particular functionality of the glyphs. You can essentially put any variants you want to them. On several occasions, I have made them work together with other features, e.g. smcp or onum.

Adam

I can’t think of a case where “ss01”-“ss20” could be hacked. These features are intended to be “non-semantic”...

So hacking a stylistic set feature would involve using one to impose a semantic distinction, but that is true of pretty much any GSUB feature. The kind of example that comes to mind is using s stylistic feature to substitute a semantically meaningful variant that is not a true variant of the underlying character code. For example, in some Greek typesetting certain letters might be printed upsidedown, and this is semantically meaningful because it indicates a distinct pronunciation, and these forms really should have their own Unicode codepoints and be encoded in the text string. But because they are not (yet) in Unicode, some intrepid font developer might decide to treat them as stylistic variants of the regular letters. I would consider this to be a hack.

What if a font has both a bi-cameral and one-cameral “g” and a particular textual application considers both variants necessary and imposes semantic difference?

There are more things in heaven and earth, John :)

A.

What if a font has both a bi-cameral and one-cameral “g” and a particular textual application considers both variants necessary and imposes semantic difference?

Then the mono-storey ɡ should be encoded as U+0261.

There are more things in heaven and Unicode, Adam :)