Then your users find that their own memory of where to find things and how to perform tasks is unreliable. Has the system changed or they forgotten it? You're effectively "gaslighting" your users if you rely on this.

Apple gives users APIs at the level they think users should be operating, not system internals.

Are we seriously having this discussion, HN? Did people just wake up today to what their reality has been for years? https://www.youtube.com/watch?v=ilcRS5eUpwk

If they rely on you (you being apple here). It's their fault for relying on undocumented interfaces. Consequently, they should stop using your system but they don't.

I agree that there's a trade off between detailed documentation and flexibility, but I think regularly leaving out details to allow for frequent changes can be a red flag. Unless your project is new and in beta, you probably shouldn't be changing things that often. After all, even if your documentation is sparse, users are going to start expecting certain behavior just from using your project.

You can also tweak this tradeoff a little. If you explain up front that what you're describing changes a lot and don't put it in the official documentation [0], you can be somewhat detailed and still have room to change.

[0]: Think a wiki or blog that your project maintains.

On the contrary, that makes documentation especially important so you can figure out if some changed behavior is a bug, a mistake on the user's side, or intended.