Annex K isn't being adopted because it's unergonomic and doesn't solve the problem it purports to. Even the proposer (Microsoft) does not actually implement Annex K as specified in the ISO.
By the time the ISO/IEC TR 24731-1:2007 was released, and then later Annex K added to the C Standard, Microsoft had to decide if they wanted to change the interfaces to conform to the changed standard and re-implement their code bases. They presumably decided that they did not, which I think is a defensible decision.
As to unergonomic, examples please?
As to unergonomic, that's somewhat subjective. But I'm a long-time C practitioner and that's my feel of the API. Constraint handlers are a mistake. Ambient state that is not part of the function interface, as well as asynchronous interaction, make for poor APIs. Constraint handlers are a mismatch for library use of safe functions, as well as kernel environments.
Most functions seem pointless; e.g., snprintf_s. Re-adding gets() in the form of gets_s() seems unhelpful. Why bsearch_s, qsort_s, memcpy_s/memmove_s?? Do you really think strerror_s() is useful? Or strnlen_s()?
Microsoft just changed one bit of the proposal, but no one followed them there. Currently it's the most widely used and worst implemented. I tested all of them.
It solves the bounds checking problem better than _FORTIFY_SOURCE, ASAN and valgrind, because it does the checks always, if compile-time or run-time, independent on the optimizer, the used intrinsics, where valgrind fails, and is much faster than ASAN. Also faster than glibc btw.