This seems not entirely accurate. "malloc_usable_size" was only recommended for use for statistics before the change in man page: "Although the excess bytes can be overwritten by the application without ill effects, this is not good programming practice:" and "The main use of this function is for debugging and introspection". The new version makes it clearer. You can find the change here:
https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/...
Also no code is "actively broken" by a documentation change. If it happened to work before it still works today. Also I do not see how __builtin_dynamic_object_size is broken. It works as intended and can be used with conforming code just fine. It is simply not compatible with some questionable use of "malloc_usable_size".
It's not the documentation change that's the problem. It's the fact that they changed implementation-defined behavior to undefined behavior in the first place (then changed the documentation to follow). Or equivalently, they changed "recommended" to "required".
In particular, the "without ill effects" is no longer true. It's possible to #ifdef to detect broken libc/compiler combinations, but I'm not confident that avoiding explicit use of __builtin_dynamic_object_size will prevent optimizations from taking advantage of false assumptions based on __attribute__((malloc)).
Also no code is "actively broken" by a documentation change. If it happened to work before it still works today. Also I do not see how __builtin_dynamic_object_size is broken. It works as intended and can be used with conforming code just fine. It is simply not compatible with some questionable use of "malloc_usable_size".