Pieter Wuille gave an amazing answer related to the connection between nSequence and nLocktime in the early days of Bitcoin.
However, based on his answer it looks like the nLocktime was NOT really originally intended just for the absolute time lock in sense you cannot include this transaction in the blockchain before the UTC timestamp/block height defined in nLocktime pass.
As I understood, nLocktime was more intended to work together with the nSequence as a time bound in sense how much time we will wait in mempool for the transaction to become final in context of replacing, than to be just absolute time lock. If we want our transaction to immediately become "final" (ready for the blockchain) then we just need to set all nSequence to 0xffffffff. Since there will be no replacement, there is no need to wait for anything, so the nLocktime value is ignored. Also, we can set nLocktime to zero and since we don't wait any time for the replacement, in this case the transaction also becomes immediately "final" regardless of the value of nSequence.
So I would say that the nLocktime is originally intended to be the time in which we will wait for a replacement. However, as we can set the nSequence to, for example, 0xfffffffe and never increase it and set the nLocktime to some time (UTC timestamp/block height), then the nLocktime indirectly becomes, and can be used, as the absolute timelock.
As addition. It doesn't work that way today. This relationship between the nSequence value and the nLocktime value still remained as a consensus rule (would require hard fork to change), so if all nSequences are 0xffffffff, then the nLocktime value is not considered, and otherwise nLocktime can be used as an absolute timelock. However, replacement today has nothing to do with nSequence (it just must be less than 0xffffffff-1 and that is all), nor wait for nLocktime time.
What do you think? What was the first original purpose of the nLocktime? Am I right?
