A side effect of this proposal is it would seem to make it not possible to produce a signature for a transaction without having access to the inputs. This is limiting for a number of cases where you don't care about that data. There are a litany of use cases where you don't want to have SIGHASH_ALL behavior, and having to sign the scriptpubkeys breaks that. So at the very least it should respect other flags.

I agree, sha_scriptPubKeys should be included only if hash_type does not match SIGHASH_ANYONECANPAY. I am also sympathetic to aj's idea of making the scriptPubKey field dependent on hash_type matching SIGHASH_ANYONECANPAY.

I also don't really understand the exact attack. So you submit a transaction to the wallet asking them to sign input 10. They sign. They've committed to the signature being bound to the specific COutpoint and input index, so I don't see how they wouldn't be required to sign a second signature with the other output too? Is there an attack you can describe end-to-end relying on this behavior?

For example, in a CoinJoin transaction the attacker can construct a transaction with two inputs (in1, in2) of identical value and two outputs of identical value, one belonging to the user (user_out) and another belonging to the attacker (attacker_out). If such a transaction is sent to the hardware wallet twice with in1 marked as external the first time and in2 marked as external the second time, then the hardware wallet will display two signing requests to the user with spending amounts of in2 - user_out and in1 - user_out respectively. The user will think that they are signing two different CoinJoin transactions, while in reality they are signing two different inputs to a single transaction and sending half of the amount to the attacker.

As an alternative proposal, I think you can just make a separate BIP for some new sigash flags that can be reviewed separately from taproot. There's a lot of value in investing in figuring out more granular controls over what the signature hash is you sign, which may have some exciting contracting implications!

The proposal of adding sha_scriptPubKeys is just an optimization which is not intended to change what the signature message is committing to. Thus I don't see it as warranting a new sigash flag.

Alternatively, there's the scheme described in the email you linked by Greg Saunders (with the scheme co-attributed to Andrew Poelstra), which seems reasonable to me.[1]  It's only downside (AFAICT) is that it requires an extra one-way communication from a signing device to a coordinator.  For a true offline signer, that can be annoying, but for an automated hardware wallet participating in coinjoins or LN, that doesn't seem too burdensome to me.