If you want the behavior of a "modular transaction", you can simply create multiple transactions and broadcast them simultaneously as to Instant Send Lock at the same time.
Why no SIGHASH_SINGLE?
SIGHASH_SINGLE requires that the index of the signed input matches the index of the signed output.
BIP-69 addresses the security issue of leaking information about the sender and receiver by ordering inputs and outputs.
Transaction output amounts (as 64-bit unsigned integers) are to be sorted in ascending order.
In the event of two matching output amounts, the respective output scriptPubKeys (as a byte-array) will be compared lexicographically, in ascending order.
If the scriptPubKeys match, the outputs are considered equal.
Therefore, in order to use SIGHASH_SINGLE without creating a vulnerable transaction, you would have to create a situation in which the inputs and outputs have the same indexes - which would severely restrict how the transaction is constructed:
All Inputs have the same amount, and all outputs have the same amount
Output addresses are chosen not by their index of next availability, but by the lexicographical order of their hash
Or it just becomes mind-numbing to try different combinations of coins to get some that just happen to work - possibly by creating new coins and transactions to them
Since this is so complex and nuanced and easy to get wrong and hard to get right, it's simply not supported.
Workaround
If you want the behavior of a "modular transaction", you can simply create multiple transactions and broadcast them simultaneously as to Instant Send Lock at the same time.
Why no
SIGHASH_SINGLE?SIGHASH_SINGLErequires that the index of the signed input matches the index of the signed output.BIP-69 addresses the security issue of leaking information about the sender and receiver by ordering inputs and outputs.
Therefore, in order to use
SIGHASH_SINGLEwithout creating a vulnerable transaction, you would have to create a situation in which the inputs and outputs have the same indexes - which would severely restrict how the transaction is constructed:Since this is so complex and nuanced and easy to get wrong and hard to get right, it's simply not supported.