This change would cause issues with copying script templates from v0 to v1. Additionally, there was a suggestion to pop the stack after OP_CLTV and OP_CSV to save weight units. However, this change could affect constructions that avoid the DROP. The developers acknowledged the potential tech debt but did not have strong opinions on the topic.During a discussion between Russell O'Connor and Johnson Lau, it was suggested that disabling CHECKSIG* and CHECKMULTISIG* in favor of CHECKDLS, CHECKDLSVERIFY, and CHECKDLSADD with different names and opcodes would result in script template failures. It was also proposed to pop the stack after OP_CLTV and OP_CSV to save weight units. Although these suggestions were considered bikeshedding, having identical semantics for opcodes in v0 and v1 scripts was seen as beneficial. However, constructions that rely on an expected true value on the stack would not work if an empty stack is required.Johnson Lau proposed a change to Bitcoin Improvement Proposal (BIP) 114 in an email conversation dated December 17, 2018. He expressed concerns about potential consequences, such as people losing money by copying existing script templates. Lau also suggested popping the stack after OP_CLTV and OP_CSV to save weight units. The decision on implementing these changes remained uncertain.Russell O'Connor proposed a change to the Script language in Bitcoin in a bitcoin-dev mailing list. The proposal aimed to require an exactly empty stack for success, eliminating the need for special logic to handle top-level CHECKSIG versus mid-level CHECKSIGVERIFY. O'Connor acknowledged similarities to his previous proposal in BIP114 but expressed uncertainty about potential negative consequences. Another related topic brought up was popping the stack after OP_CLTV and OP_CSV.Anthony Towns suggested a change to script composition in a discussion among developers on the bitcoin-dev mailing list. The proposal was to require an exactly empty stack for success, making the script more composable and eliminating the need for special logic. This suggestion prompted further discussion on the mailing list.The article discusses potential improvements to the Bitcoin system, including a new segwit version, different length segwit v1 public keys, a new segwit v1 script version, and additional opcodes. Changes proposed include introducing 33-byte v1 witness addresses that encode a secp256k1 ECC point and using new Schnorr ops to replace ECDSA CHECKSIG/CHECKMULTISIG ops. The author notes that these changes are modest compared to other possibilities such as graftroot and cross-input signature aggregation. The article also provides an example of how Eltoo could work in a taproot world and describes preparing HTLC outputs for SHA256 preimages and secp256k1 preimages. The suggestion is made to implement simple OP_SUCCESS upgrades alongside schnorr/taproot/etc. independently at the BIP/concept/implementation levels.