Are transactions with multiple real inputs bound to require all the real inputs

Question

I was reading this discussion on adding nLockTime to Monero, and the OP says that we can achieve this functionality by having a small amount of cryptocurrency transferred with an transaction-unlock-time and use this as a lock by having a multiple input transaction with this locked account to create a transaction that won't be valid until some time in the future.

The question is are these multiple real input transactions binding? Meaning I have money in a 2-of-2 multisig account A where I own one of the keys and money in account L, where L is locked using transaction-unlock-time, and I have transaction that will be valid using A and L as real inputs back to to an output I hold (will be valid after L unlocks).

If I was a bad actor, could I separate the transaction and just send the money from A back to me by separating the transaction? Or is this a hard problem?

EDIT: The paragraph talking about multiple input is as follows: "It is technically possible to implement nLockTime now (without protocol change), but it is a little clunky. You have to put a negligible amount of Monero in a time lock transaction, and then sign a transaction spending it and the funds you want to nLockTime. This won't be publishable until the other transaction is unlocked, but it is a little clunky, requiring a couple of transactions (and data must be published to the blockchain)." The bold section implies a multiple input transaction.

Answer 1

The OP workaround does not actually mimic a Bitcoin nLockTime tx, because the second tx (with the actual funds), is not published - it cannot be, the network would reject it. An nLockTime tx is actually published to the network but cannot be mined (included in a block) until the specified time has passed.

The moment a Monero tx is published, it can, and almost certainly will within 2 minutes, be mined. And as soon as it's mined/confirmed on the blockchain, it is final, even if it has an unlock time set (ref this answer). This means the output(s) of that tx cannot be spent (used as inputs) in another tx, until the unlock time has passed.

Therefore, if you set an unlock time on a tx destined for a multisig wallet, the outputs of that tx, which are now owned by the multisig wallet, need to both pass the unlock time and be signed by both wallet participants to be spent. The tx cannot be cancelled and it can only be refunded* (sent back) once it has passed its locked time and signed by all participants.

(*) I say refunded here, but this is actually just a normal, manual, spend. There is presently no such thing as a tx refund address in Monero which would allow a more automated refund.

Pulling this all together, dissecting your question(s):

The question is are these multiple real input transactions binding?

The moment a valid tx is sent to the network and mined/confirmed, it is binding. The input(s) must have been unlocked and you must have had the signing key(s) for them.

Meaning I have money in a 2-of-2 multisig account A where I own one of the keys and money in account L, where L is locked using transaction-unlock-time, and I have a valid transaction using A and L as real inputs back to to an output I hold.

You simply cannot have a situation like you have described here. It cannot be both "in a 2-of-2 multisig" wallet (locked or not) and in another wallet (locked or not). The moment you send (publish) the output to the multisig, it has to have been unlocked in your source wallet, and even if you specify it is to be locked when received in the multisig wallet, you cannot do anything with it after in the source wallet (it is now spent, regardless if it is now locked or not).

If I was a bad actor, could I separate the transaction and just send the money from A back to me by separating the transaction? Or is this a hard problem?

Given you have defined A as a 2-2 multisig, the only way you can send it back to yourself is by having both the other signer sign this new transaction sending it back to you and the funds not being locked in the multisig. There is no gaming this.