This is an interesting point; without some sort of “stack sentinel” that guarantees a specific script type, using CTV as a gadget for any P2SH type seems broken, as you can replace it with a legacy script that does something else. This is “confusing” because you cannot replace it with a p2sh script that does something else. I can make an effort to better document this issue…
wrt the legacy requirement, what you can do is as follows:
use a legacy input B which has
scriptSig: [other program stuff] <sig || ALL|ACP > Dup <pk> checksig
script: <pk> checksig
you are free to include more inputs like this for more data.
What you can also do is employ a taproot-adapter to create B. That is a output X like:
tr(NUMS, {[general program] <1-in-1-out w/ <pk> checksig> CTV)
You can then bind B as usual from A, and A’s commitment to B’s Outpoint via B’s signature guarantees that the output X has executed. So if you were relying on X for knowing some other validation property has passed, you can move most of that work into the witness data space.