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.