I think the core message that I wanted to put out is that each operation that the XCM executor performs doesn’t have to always match 1-to-1 to any on-chain operation. Applying this principle to the problems you’ve mentioned, the solution becomes simple:
Answer: sure, the XCM executor sometimes requires 2 instructions to accomplish a transfer, but that does not mean you need to map each XCM instruction to exactly 1 on-chain operation. This is in essence the same idea behind compilers, microcode and VM instructions – they all don’t have statements that correspond 1-to-1 with the machine code of the target architecture, and so do the XCM instructions vs on-chain operations.
Answer: store some metadata on the Substrate side for the ERC20 token for the on-chain “holding account”, detailing how much of the asset is actually in holding and how much of them is trapped, and do verification checks on every DepositAsset or ClaimAsset instruction to ensure you never overconsume assets that was not meant for the other.
Answer: first, blackbox the XCM executor, and think about what it ultimately does. It essentially consumes some encoded data, and then somehow understands that some funds need to be transferred from one account to the other. In other words, if you view one XCM as an entire transaction, then all that matters is that you gather which accounts need to be debited and which accounts need to be credited. The details of how the credit and debit is connected lies within the exact instruction used, and you can determine that by examining them.