What happens when relative and absolute lock times are used in the same transaction?

Question

BIP 68 redefines the input sequence number field as bit vector that encodes a relative lock time.

A transaction can be encumbered with an absolute lock time by setting the nLockTime field to a non-zero value and by ensuring that at least one input sequence is non-maximal (not 0xffffffff).

What happens if a one-input transaction sets nLockTime > 0 and introduces a relative lock time under BIP 68? For example, nLockTime might expire in 12,000 blocks and the input's relative lock time might expire in 11,000 blocks. Conversely, the relative lock time might expire after the absolute lock time.

Which locking mechanism wins in these cases? Are both locks checked, or only one? If the latter, which one?

The "Compatibility" section of BIP 68 hints that both locks will be checked, but from my reading doesn't state this explicitly:

The only use of sequence numbers by the Bitcoin Core reference client software is to disable checking the nLockTime constraints in a transaction. The semantics of that application are preserved by this BIP.

Answer 1

When a specific locktime is specified in the nLockTime field in a transaction. It means that said transaction cannot be broadcasted/be accepted by miners until either the blockheight or unixtime has elapsed.

On the other hand, when a OP_CSV is used, it means that a transaction referencing said input cannot be spent until some blockheight or unixtime has elapsed.

If we merge both and use them together, basically, we will create a transaction that cannot be broadcasted to the Bitcoin network until some nLockTime has elapsed and it also cannot be spent until some blockheight or duration of time has elasped. OP_CSV specifically targets the spendability of a transaction, whereas a time-locked transaction simply prevents some transaction being broadcasted to the Bitcoin network until its locktime has elapsed.