> A lot of software should change in order to adapt to emerging requirements.

True, but your tests should still aim to be testing the type of thing that will never change unless a customer requirement is changed, not because you want to refactor something.

This is of course impossible, but it should still be your goal.

>Your APIs also have users

Exactly - so test those APIs that have users, not the internal implementation details. If an API has users it quickly becomes an Augean Stables problem to change them and so you won't touch that API if you can at all help it (you may add a new/better way and slowly convert everyone, but it will be a decade before you can get rid of the old one)

> To other programmers, the implementation of a library, module, or even a single function can be a detail

other programmers are sometimes customers/users. If you are writing a logging system (what I happen to be working on today) your end users may never be allowed to see anything related to your system, but you expect to quickly have so many people calling Log() that you can't change the interface. By contrast you may be able to log to a file or a network socket - test those two backends by calling log() like your end users would and not be calling whatever the interface between the frontend (that selects which backend to use) and the backend is.

Again, the goal is to never update tests once written. I'm under no illusions you will (or even should) achieve this, but it is the goal.