Thanks for filing this. Yes, the behavior has changed: previously, FontSubstitutes were applied "eagerly", so that when a given font name is requested (e.g. by the CSS in a page), Firefox would check for a FontSubstitute entry for that name before attempting to look up the original font. So substitutes always got used. The new code first looks for the font exactly as requested, and only falls back to checking FontSubstitutes if the original isn't available.
It's not entirely clear to me which behavior is "correct" here; I think it could be argued either way. At https://docs.microsoft.com/en-us/globalization/input/font-technology there is a brief section about "Font Substitution", which says that:
Font substitution is implemented by an application to replace a request for a font that is not available into one that is available.
To me this suggests that Firefox's new behavior is correct: substitution is performed only if the requested font is not available. This also matches how other browsers and applications handle things, according to the discussion I've seen.
However, I can see that the change may be frustrating for users who have been deliberatly using registry FontSubstitutes entries to "globally" replace a font, such as swapping the Segoe UI system font for something else, or who have unknowingly relying on default substitutes such as Helvetica->Arial, which meant that installing a "broken" Helvetica family such as a single, compressed face would essentially be ignored rather than start showing up on web pages.
Given that the updated behavior better matches other browsers, I am reluctant to simply revert it; in general, interoperability is more helpful than having each application interpret the system font configuration in its own unique way. But maybe we can implement an option to enable "eager" substitutions for those users who prefer it. I'll try to look into the possibilities.