My perception of the official documentation of the language (the Language Guide) is that it is quite high-level and only covers user-facing features. Beside some exceptions, it basically never mentions how most things work under the hood. This makes the initial introduction to the language generally concise, which is a good thing; however, beyond this level, there's basically zero to none resources (especially official) that would provide interested users with a deeper view into the internal mechanisms of the language features.
My personal story with this is that, being very careful about my code on the one hand, and having a genuine interest for low-level mechanisms on the other, this state of things left me feeling somewhat lost whenever I tried to get a good enough understanding for some features, in the end abandoning the idea of incorporating them into my code because I oftentimes just wasn't sure if they were doing what I was thinking they would do. A good example for me is async/await: it was clear for me from the docs (and overall exposure to programming trends) what async/await is essentially doing, but I never could grasp how exactly it was doing its thing until I allocated myself a cozy weekend of extensive research watching great in quality, but scarce in numbers, talks on Swift's inner workings like this one.
To perhaps generalise beyond my personal anecdotes, I think one would agree that developing a better intuition for the internal logic of a programming entity, be it a language feature or a data structure, leads to generally better code. The oder side of the coin could be that without sufficient intuition, one might unknowingly misuse those said feature.
Now, the previous paragraph might have been trying to present an obvious argument, but sometimes I had a feeling that some documentation tends to intentionally operate with generic "rules" as in "the use of X is discouraged" or "only use Y if you're sure" without pinpointing what exactly the problem could be, and I have a feeling that this could have something to do with the so-called Hyrum's law. Which makes me wonder—and this now refers to the question in the topic's header—is this a somewhat deliberate policy that if some sort of behaviour has not been declared guaranteed, then it shouldn't be exposed within any official documentation?
It is obviously not a non-goal to document those implementation details that genuinely are subject to change at any point; however going back to the async/await example, I would assume that it's most likely the case that the particular coroutine implementation will be there to for more than a minute, and just understanding how it works would improve the code of many by a lot.
So, would the Swift community be interested in expanding the docs to include some of the internals for educational purposes?
The obvious example to close off my message is Rust's Nomicon. I terribly wish Swift had something like this resource.