here's an idea: instead of projecting a human concept of the roundness of a date onto the technical solution, let's use a value optimized for efficient implementation.
Obviously if you move toward 64 bits, as most systems have already done, you don't have a problem.
So if you want to stick to signed 32 bits, let's instead agree to restart counting 32 bit UNIX timestamps for the new epoch at exactly Sun Feb 7 06:28:16 AM 2106 UTC.
Sure, it's not a very round number in human terms, but has the advantage of requiring significantly less implementation.
Of course you still have the same problem of knowing which epoch you are in, but that's intrinsic to the problem when you only have 32 bits.
And why not 2000 while you're at it, to keep it even?
Great idea - for shiny new systems, at new companies, that will never see any date older than Jan 1 2020.
But for other use cases - not so great.
Why?
Sounds a bit like a solution in search of a problem.
There's no reason you can't use a 64-bit value in a 32-bit system. Much simpler to access the 64-bit value as two 32-bit words than propose a whole new confusing and ambiguous system.
In terms of current-time coding, the only time that second hi-order word would be used is when the lo-order word overflows, and on initialisation of the 64-bit variable. And if needs must, it could even be a compiled-in value, seeing it will only change once in every 68 years.