Undoubtedly, you are right and the method must be extremely reliable so that neither side can deceive the other. Without this, the whole idea becomes meaningless.

To avoid this, an intermediary program is needed, which will unfreeze access to ETH only after BTC is received.

This is what a smart contract is for. The intermediary program, when sending BTC to the desired address (but not yet fully confirmed by the network), creates a smart contract with the conditions "freeze the equivalent of the amount ETH sent by the user to BTC for the period of waiting for confirmation." After BTC arrives at the address, the intermediary program will unfreeze ETH account. Or, the program will not be able to influence the smart contract after it is created (which should be more reliable), and the account will unfreeze after a certain time, sufficient to confirm transaction BTC.

This is only a draft version, completely devoid of grace for solving the desired problem.

I understand. Thank you for reminding me of this.   In my idea, networks BTC and ETH do not intersect in any way. Iintermediary program, which, just does not allow one of the parties (mixer and user) to scam, connects ETH and BTC networks (conditionally), checks the receipt of the required amount to the addresses, controls the fulfillment of the conditions.

Yes, commitment sounds the closest.

It is possible and if so, then I apologize that I wasted your time with "inventing the wheel". I don't know anything about submarine swap or and first saw the term in your post, but I'll look through your links and try to learn more about it.