The paper PDF by the IBM researchers: https://arxiv.org/pdf/2606.13445v1
From just the abstract, I'm a bit alarmed that the researchers believe that "cryptographic agility" is reducible to a software engineering problem, rather than a complex function of regulatory (eg PCI-DSS), governmental (eg FIPS), and availability (eg hardware acceleration/support and robust implementations) considerations.
But even before all of those stakeholders get involved, is cryptographic agility still an operational objective? Sure, there's the matter of transitioning to PQ crypto, for scenarios where HNDL is a serious concern over the time horizon of whatever's at stake. But is that perceived as a one-time event, or is the idea that all future upgrades should be abstracted?
I find the latter a bit difficult to credibly believe, as the last major attempt at cryptographic agility was so thoroughly bungled that JWT alg:none has a website to highlight the problem.
Agility is only useful if it's actually moving forward: if instead it's an excuse to stand in place, then it's worse than nothing. Best I can tell, this paper seems to deal with abstraction of specific implementations of cryptographic libraries. So this would be akin to not binding directly to OpenSSL vs BearSSL, but having the ability to swap one out for the other.
In that more narrow sense, a lateral move like that is probably fine to abstract. But I can't see how this would fair well if used to shoehorn newer cryptography into applications that either are firmly dependent or are brittle in other, in-abstractable ways.