> The BIP (119) says P2SH is unsuitable for this,
What BIP119 says is that P2SH is incompatible with OP_CTV if the opcode does end up requiring a commitment to the scriptSig hash. I must admit I don't quite understand where the hash cycle occurs there.
It's probably because the scriptsig is not only in the main transaction hash but also inside the presignature. So you can't fill in something else in the preimage's srcriptsig's place because unlike for the main transaction hash, there's no scriptPubKey we can fill in the place with, making it impossible to make the presignature.
> so this limiting script that's supposed to act as a smart contract will be a raw redeem script?
I don't think I quite understand your question. Would you mind elaborating?
In other words, is the redeem script the one limiting the destinations, but according to your reply it's the outputs hash in the presignature.
> There's also the major issue of barring simple arithmetic and crypto (hash160) differences between addresses, the scripting system can't filter addresses based on complex conditions.
Not sure I follow this either. Are you saying OP_CTV bars arithmetic? Or are you talking about bitcoin Script in general?
Bitcoin script is limited to basic expressions which makes it bad for trying to filter which transactions are allowed for a UTXO, because usually in a smart contract you want to make conditions that the output hashes match those coming from, for example, an exchange or other service. That's well beyond the capabilities of bitcoin script.