> The primary being it’s easier to keep the documentation up to date ...

That's NOT a "good" reason in any sense.

That's a terrible reason, which no-one in a team leader or above position should ever sign off on.

We're going to have to agree to disagree on this one. But let me give you all an example.

Wolfram Documentation on Mathematica is excellent in my humble opinion. Here is a function I use very often, convolve.

https://reference.wolfram.com/language/ref/Convolve.html

Notice how the interface is very well described, there are examples on how to use it, but there are no implementation details.

Your reference example includes lots of details, examples of usage including source, explanation of options, etc. :)

That's not an "easier to keep documentation up to date" type of thing ;), but is definitely an example of good documentation.

Unlike the Apple approach mentioned above. :( :( :(

Following that reason, the easiest way to keep the documentation up to date is to not have documentation.

It’s always the null cases that get you... I suppose if “up to date” was the only requirement I would agree. But in reality there are many competing requirements which is why there are many degrees of documentation. Obviously internal and external documentation will be different too.

The reason to keep implementation details out of the docs is that people will rely on those implementation details, and then when their app breaks, they won't even think of looking at the documentation for updated implementation details. After all they probably have the old version all but memorized, and the app may break in a way that isn't obviously related to the implementation that changed.