> just decided to avoid the burden of publishing and maintaining an immature or lesser used API
"Burden" is an understatement. Any API Microsoft documents becomes part of their ongoing commitment to eternal backward-compatibility. (Heck, even some things they never document at all still end up forced into that commitment, like the internal registry hives in Windows 95.)
So Microsoft do everything they can to only document what they're absolutely sure they have in a good, stable, "won't regret later that we didn't fix it some more before setting it in stone" state.
While that may be true for the Win32 APIs, it is certainly not true for their cloud-based products. They’ve had some very poor APIs for Windows Live Mail (predecessor of Office 365 for education) which were also quickly deprecated and replaced.
They could just flag it “volatile”, “unstable” or something.
It’s very unlikely that Microsoft did not properly document the api internally and as you see it’s leaking out anyway.
If you'll ever develop a single simple API you'll find out that doesn't work at all. People will use unstable APIs and people will blame YOU and only you when they break.
"Burden" is an understatement. Any API Microsoft documents becomes part of their ongoing commitment to eternal backward-compatibility. (Heck, even some things they never document at all still end up forced into that commitment, like the internal registry hives in Windows 95.)
So Microsoft do everything they can to only document what they're absolutely sure they have in a good, stable, "won't regret later that we didn't fix it some more before setting it in stone" state.