> Changing the microarchitecture itself is not trivial either
Major changing is not trivial. However I can see how they can implement minor tweaks between revisions that don’t affect their main interface (i.e. AMD64 instruction set + extensions) but do affect microcode.
> you can bet that they've got it all documented internally
I’ve worked in a couple of large US software companies. I won’t point fingers but the internal documentation I’ve worked with wasn’t OK. The only exceptions is when the company provided a public API. When that was the case, they allocated resources (developer’s time, plus sometimes a technical writer position) and did the job.
> along with tools and whatever else
Legal issues are likely. E.g. GPL-licensed code is fine in an internal tool, but if you want to distribute it, you have to also distribute the source code of everything else that’s linked. Sometimes you don’t want to, other times you just can’t (if it links to a commercial library you’ve bought).
> because there are things in there that they don't want the world to know
I don’t eliminate the possibility but I don’t think that’s likely. As you see, there’re pragmatic reasons (i.e. money) why they aren’t doing that.
The good thing is, if anyone (Intel, AMD, I dunno, Apple, Qualcomm) will do that, and it will indeed deliver a great value to the users (such as free ASAN), the rest of them will do the same really fast, because competition.