Does the font have the same name as before? If so, it could be a font cache issue. Barring that...

How does it look if you import the generated font back into FontLab?

The name of the new version has pro at the end to distinguish it from the previous. I don't think it's a cache problem. I used the cache deleting features in Font Explorer and even tried restarting.

I did open up the font itself in FontLab. That changes around the names of classes, but the code was essentially the same and the glyph slots were all intact. I tried copying just the affected ligatures back in and deleted all the contextual elements for them. The same ligatures still would not come in. Very frustrating. The older version that I tried that worked was a ttf version of OpenType. I'm wondering if that might make a difference, but I'm not sure.

When I made the updated version with all the stylistic sets for caps I rearranged the sets and changed orders around a bit. I don't see any for the lowercase where I've changed the hierarchy, but that's the one thing that I keep thinking might be involved. I also wonder if fonts just go corrupt sometimes without any noticeable changes that should affect them. When I worked at AG some of our old PS fonts would just stop working and I couldn't always find a clear answer even though an archived version still worked.

I also wonder if fonts just go corrupt sometimes without any noticeable changes that should affect them.

I used to have this problem on Mac OS, when I still used PS fonts.

It seems to me that it must be something you inadvertently did in the OT code. Something subtle that doesn't raise an error when you generate the font, but causes the behavior in InDesign. Just a hunch.

BTW, I say this because I'm pretty sure OT fonts can't get corrupted the way old PS fonts could. The reason they did (on the Mac, anyway) was to do with the fact that they were stored as resources (i.e., in the resource fork of a file). Because of the way resources worked on the old MacOS (pre-10.0), any font files that were installed had to be open (for read and write) while in use, and if a file was open when a system crash happened, it could be corrupted. Since installed fonts were always open, that made them vulnerable to corruption. Fonts don't work that way anymore on MacOS 10.0 and later (except in the Classic environment, but hardly anyone uses that anymore, and it's not even possible on 10.5 and later or on Intel-based Macs).

That said, I have heard of FontLab .vfb files getting corrupted.

Thanks, Mark. Yeah, I had never had problems before with OT fonts like PS ones. I'll keep trying to figure it out and see if I can find an error.

How does it look if you open the generated font in FontForge?
(FF reports errors even in widely used fonts)

I have heard of FontLab .vfb files getting corrupted

I have experienced it, and it's no fun. Generally, the only way to correct the problem is to generate a font, and open it up in FontLab. This procedure usually removes the voodoo hidden deep inside the original .vfb, but you have to check your Font Info, Classes and Features to make sure that they haven't changed.

OT Class names are likely to change when doing that, Nick. They seem to default to some typical word followed by numbers to indicate which set gets swapped by which other.

sub @smcp1 by @smcp2;

is typical.

The reason that happens is because the feature source code is not stored in the generated font. It gets compiled. So when you import the font back into FontLab, it must decompile the feature code. Some of the original structure is lost, even though it is (usually*) functionally equivalent.

One way to get around this is to export the classes and feature code from the original .vfb. Of course, if that's where the problem was, maybe not. It would be worth testing the OT features of the imported font in FontLab--as it interprets them--to see if the behavior in InDesign is present.

* There are some OT features that FontLab doesn't know about that may be present if the font was not created in FontLab. But that's not going to be the case with your font.

I learned the hard way to regularly save classes and features. FontLab giveth and FontLab taketh away.

I've had similar problems with a 2500+ glyph font. TT worked fine, but CFF didn't. Turning of "compress outlines" did the trick. B.t.w. some of the errors would be that a blanc would show up, but was visible in a PDF.

OT Class names are likely to change when doing that, Nick.

I learned the hard way to regularly save classes and features. FontLab giveth and FontLab taketh away.

The generate font trick is better than starting from scratch and, as you noted later, saving classes and features is the way to go as Standard Operating Procedure.

"The generate font trick is better than starting from scratch"

Amen, brother ;-)

If you're using a Mac, Tal Leming's FeatureProof utility could possibly be useful for debugging.

I tried opening up the generated font, but only to look at it. What I ended up doing, howeve,r was really simple. Apparently the corruption only happened when I generated a PS flavor OT font. I did it as a ttf and now have no corruption. Not sure what caused the problem, but I found an older version that I had made as ttf before the upgrade and it worked so I tried that format.

Have you tried Micha's suggestion? Sounds like that might be what's going on if the OT/TTF version works okay.

Thanks, Micha and Mark.
I was away awhile and missed Micha's comment. I just tried that and it works! That's fantastic.

Great! Now show it :)
b.t.w. It seems to be related InDesign. Quark doesn't have this problem.

It is look like "dramatical dialog" with happy ending, :-)
Thanks for all lesson inside.
Best Regards.