Year 2038 problem and year 2106 chain halting

One user suggested that a 'k' value representing the most significant 32 bits of a 64-bit timestamp should be stored in all cases where time is used to avoid confusion around whether timestamp zero is related to 1970 or 2106 or some higher year. Skipping 'k' could cause problems related to OP_CHECKLOCKTIMEVERIFY or nLockTime. Another user suggested adding the 'k' value to the coinbase transaction and combining two 32-bit values, the lower bits from the block header and the higher bits from the coinbase transaction. Additionally, adding the 'k' value to the nLockTime field in a similar way as transaction witness was added in Segwit may be necessary. The same is needed for each OP_CHECKLOCKTIMEVERIFY, and pushing high 32 bits before the currently-used value may solve that. While this is a hardfork, it's not one that needs to take effect for many years, and as such, anything can be done as long as it doesn't change anything now. However, ideally, a hardfork requires upgrading every node that can be upgraded, or at least have the node operator's consent to lose the node for every node that can't be upgraded.