Microsoft considers documentation status and long term support status to be the same thing. If the behavior of a function / API is not going to remain stable, it isn't documented. If they don't want to pay maintenance/support costs for an API (more rigorous testing, sample code, etc) the API won't be documented.

Historically Microsoft had a 100% back compat guarantee for APIs, so the second an API was documented its external interface was frozen in stone forever. There are still APIs around to this day that have misspelled struct fields because someone made a typo 30+ years ago.

If an API isn't documented it is "use at your own risk", although if enough large software starts depending on it, the API may have to be frozen anyway (or compatibility shims put into place) to avoid breaking popular software programs.

Yeah, I wasn't trying to be snarky, rather there often seems to be a "private code shouldn't exist, code wants to be free!" ethos that makes my eyebrows twitch in PTSD from reading all of Raymond Chen's tales of depending on undocumented code, e.g.

*https://devblogs.microsoft.com/oldnewthing/20031015-00/?p=42...

*https://devblogs.microsoft.com/oldnewthing/20031223-00/?p=41...

*https://devblogs.microsoft.com/oldnewthing/20230113-00/?p=10...

*https://devblogs.microsoft.com/oldnewthing/20060109-27/?p=32...

That's not the argument; the argument is that this would be some form of "there is only one method and it is being withheld", which simply isn't the case.