I kind of get this, but what about this use case: I have software that is in production and has been for awhile. I've locked down all the versions of libraries

I kind of get this, but what about this use case: I have software that is in production and has been for awhile. I've locked down all the versions of libraries I've used (FFF works here) and everything is running smoothly. However, a large customer requests a new feature, and I see that library X has a new version that has new features that will support development for the new customer feature. With semver, I can see that this new version is, say, 2.3.0. If I was using 2.2.x, I have at least some assurance that the API I was using before hasn't changed, so the amount of work to upgrade is likely limited to implementing new features, and not converting and re-testing older code. However, with the FFF rule, it seems that the new version would change (due to form/fit (api?] or function changing), and all I know is that this version is new, and I have no indication how much work it would be to upgrade, other than assume the worst case that existing APIs have changed. I could see why the manufacturing methods might make sense, especially in certified software... but in the wild west of web development, I have a feeling it would never catch on.