2038 is closer than it seems

My feeling is that at the kernel interface side, we won't do a hard break, and keep 32-bit time_t at least for the architectures that have it today while introducing new syscalls to take to the libc.

What user space does is a different matter though. I think you should always have at least the option to build a libc that only supports 64-bit time_t in user space and that uses the new kernel interfaces for a safe implementation. This way, an enterprise distro with e.g. 10 years of guaranteed support and lots of legacy third-party applications can keep working as previously, while an embedded system with 25 years support and no legacy code can go to 64-bit time_t in user space without any backwards compat hacks in user space.