My purely personal opinion is that it should be obvious why manufacturers/vendors don't document everything in great detail: that is tantamount to making those implementation details API and promising support for some indefinite period into the future - no matter how many warnings are put on it. Any observable behavior of a system (or CPU instruction set) becomes public API over time.
People get irately angry when a warranty replacement ends up with a slightly different system (CPU stepping, firmware revision, or whatever) that breaks something. They get only slightly less angry when buying a newer system does the same: "XYZ worked on my previous system!!!!1 this is broken garbage!!1111 Widget Inc is deliberately screwing over loyal paying customers to force us to buy more widgets, it makes me sick!!!!!1111" - this is not too far off from comments made here on HN at times.
Making seemingly trivial changes becomes an exercise in walking a minefield of unknown compatibility constraints.
That's besides the extra work of hiring technical writers to spend time converting a jumble of engineering notes, comments on bug tickets, and code comments into publicly presentable documentation - and making sure to keep all of that up to date when anything changes. For something almost no one knows or cares about that you may completely change in the next version.
100% this. "API is forever" is a saying for a good reason, and writing good API takes a lot of extra work and planning - and we still frequently get it wrong.
People get irately angry when a warranty replacement ends up with a slightly different system (CPU stepping, firmware revision, or whatever) that breaks something. They get only slightly less angry when buying a newer system does the same: "XYZ worked on my previous system!!!!1 this is broken garbage!!1111 Widget Inc is deliberately screwing over loyal paying customers to force us to buy more widgets, it makes me sick!!!!!1111" - this is not too far off from comments made here on HN at times.
Making seemingly trivial changes becomes an exercise in walking a minefield of unknown compatibility constraints.
That's besides the extra work of hiring technical writers to spend time converting a jumble of engineering notes, comments on bug tickets, and code comments into publicly presentable documentation - and making sure to keep all of that up to date when anything changes. For something almost no one knows or cares about that you may completely change in the next version.