The idea is that a script type could exist which looks like a pubkey Q, but can be spent either by key spending or by proving Q was derived as Q = P + H(P,S)*G, with a script S and its inputs (Taproot script spending), or by signing a script S using Q and providing S's inputs (Graftroot script spending). Both approaches have different trade-offs, with Graftroot being more compact when dealing with many spending paths while Taproot lets you prove all the different spending paths. The question is whether it is safe to always permit both types of script spending paths or an explicit commitment to whether Graftroot is permitted is necessary. While none of the concerns raised are convincing points against allowing Graftroot spending path in all scenarios, they do raise potential issues. Accidentally signing a script could have more broad consequences without Graftroot, and in a multisignature setting, a subset of participants could remove others from the set of signers. In situations where private keys are stored in an HSM, an attacker needs access to the device and convince it to sign for every output without Graftroot, but with Graftroot, the HSM may be tricked into signing a script that does not include itself. Overall, it seems good to discuss potential reasons such outputs couldn't or wouldn't be adopted in certain applications. Links to previous discussions on Taproot, Graftroot, and half-aggregated signatures are provided.