None of these are hard components. That is exactly the problem. Every team writes them, nobody is given a week to write them, and so they ship at eighty percent and stay there for the life of the product.
Nobody chooses a product because its accordion animated well. But people do quietly decide software is cheap, and they decide it in the first thirty seconds, from a dozen small moments that were almost right.
Almost every animated component library ships all three. They are not hard problems. They are just invisible until they are not.
A label changes from Save to Saving and the button resizes, so the row beneath it moves and your cursor is suddenly over something else. Every state a component can reach has to reserve its width before it gets there.
You click again halfway through and the transition restarts from the beginning, or worse, queues. A spring should resume from wherever it currently is, because that is where the element actually is.
With reduced motion on, most libraries either play the animation anyway or hide the element entirely. The information has to arrive either way. The trip is optional, the destination is not.
A file. Not an install, not a wrapper, not a config object with nineteen keys. You copy the source into your project and it becomes yours, including the parts you disagree with. The only thing it needs from you is motion.
Every component states what it refuses to get wrong, and the demo on its page can be replayed, because a micro-interaction you can only watch once is a screenshot with extra steps.
The set is not organised by widget type. It is organised by what the person is in the middle of when the interaction happens.