I think of the strange case of react-router which has been through 7 versions, many of which were complete breaking rewrites. It's hard not to come to the conclusion that since they kept rewriting it, they didn't believe in any of them. Lately they made big changes because they want to support SSR but I couldn't give a flying F because
we're not using SSR any more than I care about React Native support because
we're not using React Native! [1]
I've worked on a lot of code where people tried to use react-router and eventually gave up and have some code where they parse the URL directly and it works just fine. The trouble with react-router is that if you understand it enough to use it, you don't need it that is, you can either write some stupid URL parsing code or you can write some hooks that do 100% of what you want (as opposed to 90% of what you want with their code) with about 25% of the code.
For them it's a tiny amount of code that they understand completely and they have no problem tearing it up and rewriting it all because there is very little to it and it doesn't really do very much. [2] For you you either don't understand it in which case you feel like a hostage to their whims or you do understand it in which case you don't need it.
I am looking at a React 16 app which uses a huge number of third-party components that I badly want to take up to React 17 because of testing. With React 16 the tests can't ever really know that React is done running callbacks which makes them brittle and slow which is a bad enough situation that I don't want to write any more tests. React could have done something about it before because React knows if it has callbacks left to run but they didn't until React 17.
My understanding is that, most likely, all the components I have will work just fine with React 17 or 18 for that matter because the 16 -> 17 and 17 -> 18 transitions caused very little breakage. Their package.json files disagree so I can't just bump to React 17, but rather I have to update all the dependencies to newer version and many of them, like react-router, have a cavalier attitude about compatibility so I'd expect to spend a month at least dealing with all the breaking changes in the dependencies. It's times like this when I wish I could stick an axiom into my package.json that says "Version A of package B is really compatible with React 18" or just fork version A of package B to version A' which has a patched package.json. After all that it is certain that there will be invisible changes in the HTML which will cause us to fail an accessibility audit six months later requiring another month of work to track down.
[1] Sure, somebody else is, but I have enough problems to worry about with the modern web and patching up applications written by interns that I don't need the burden of navigating through the docs over and over and over again having to ignore 80% of the content which is completely irrelevant to me. Never mind that older versions of RR, at the very least, support obsolete methods of navigation which is another thing you don't need filling your headspace.
[2] So little code that it probably takes up more of their headspace to go to a conference and boast about what they did than it did to actually do it!