Software can be considered done with respect to any given set of requirements. Now if the requirements change, then of course, the software may need to be updated - but even then, it should be designed in such a way that the impact of requirement changes are minimal. Software should, to some extent, anticipate requirement changes. Of course this is not easy, but to claim that it's impossible is to admit defeat. You need highly skilled people making those architectural decisions.
Some software is subjected to constantly changing requirements and these can be said to never be done but that's far from being the case for all software. Libraries and modules are software too and these should be generic enough to handle requirement changes without code changes since they should not concern themselves with the business domain.
I have completed open source projects which did not need to be updated in years and worked just as well. I've worked on other projects which had to be updated because of vulnerabilities found in dependencies but these did not require any code changes on my end.
I consider it a huge red flag if some library was working fine for 5 years and then people decided to change its interface in a non-trivial way.
I was tolerant when async/await was rolled out to major programming languages; this affected and continues to affect dependencies but it's a meaningful conceptual improvement and helps with future maintainability. I hope that programming standards organizations will slow down after that in terms of changes which affect function interfaces because these decisions have huge flow-on impacts.
It's totally possible to produce completed software (especially libraries and frameworks) but the industry has to aim for it and expect it.
The current goal of industry seems to be job creation, not the creation of robust working products. Accepting that software can never be done right from the beginning is going to be a disaster. It should only be tolerated in the context of requirement changes.