No, not at all, but that's a different problem. That issue is about linkage between two different binaries that have _TIME_BITS=32 and _TIME_BITS=64, not an issue with linking to glibc. However, that's only an issue when you are dealing with software that passes time_t in the ABI. Of course, on the whole, a distribution has to deal with all kinds of weirdly-intermingled and low-level packages, so this does happen a very non-trivial amount of times surely, but in general I expect that a lot of old binary software will be alright. You'd only run into this particular problem if you had an old binary that interfaced with another library that is provided by the system that did this. I didn't check, but I'd be quite surprised to find random time_t in most popular library APIs, e.g. I don't expect to see this in SDL or GTK.
Of course, if you did need to support this case, you don't need to throw the baby out with the bathwater necessarily. You'd just need a _TIME_BITS=32 build of whatever libraries do have time_ts in their ABI, and if that blog post is any indication Gentoo will probably have a solution for that in the future. I like the idea of jamming more backwards-compatibility work into the system dynamic linker. I think we should do more of that.
In any case, this issue is not a case where glibc broke something, it's a case where the ABI had to break. I understand that may seem like nitpicking, but on the other hand, consider what happens in 2038: All of the old binary software that relies on time_t being 32-bit will stop working properly even if you do have 32-bit time_t shims, at which point you'll need dirtier and likely less effective hacks if you want to be able to keep said software functioning.
Of course, if you did need to support this case, you don't need to throw the baby out with the bathwater necessarily. You'd just need a _TIME_BITS=32 build of whatever libraries do have time_ts in their ABI, and if that blog post is any indication Gentoo will probably have a solution for that in the future. I like the idea of jamming more backwards-compatibility work into the system dynamic linker. I think we should do more of that.
In any case, this issue is not a case where glibc broke something, it's a case where the ABI had to break. I understand that may seem like nitpicking, but on the other hand, consider what happens in 2038: All of the old binary software that relies on time_t being 32-bit will stop working properly even if you do have 32-bit time_t shims, at which point you'll need dirtier and likely less effective hacks if you want to be able to keep said software functioning.