These functions are considered to be useless and complicated, falling outside of best practices. The aim of this proposal is to discourage their use, but there are concerns about potentially destroying value and leaving pre-signed transactions vulnerable.Matt Corallo suggests that soft-forking behavior into OP_NOPs or nSequence could be a useful approach to make the code more secure. However, he strongly disagrees with only soft-forking out transactions that are "fundamentally insecure," arguing that we should be willing to soft-fork out things that clearly fall outside of best practices.Mark Friedenbach raises concerns about removing these features unless they are fundamentally insecure and vulnerable. Johnson Lau proposes that disabling both functions would ensure that scriptCode serialized inside SignatureHash() must be constant. If a soft-fork is used to remove FindAndDelete() and OP_CODESEPARATOR from non-segwit scripts, all blocks before the softfork block can be whitelisted to completely remove FindAndDelete() from the consensus code later.The proposal to make OP_CODESEPARATOR and FindAndDelete non-standard in non-segwit scripts has been met with mixed opinions. While some argue that making them non-standard is a good change to discourage their use and better inform discussions, others raise concerns about potential value destruction and unknown pre-signed transactions utilizing these features. The debate also revolves around whether soft-forking out only fundamentally insecure transactions is sufficient or if features falling outside of best practices should also be considered for removal.Overall, the proposal aims to set clear best practices and improve the security of the bitcoin protocol. Soft-forking out these features would require a significant time frame, giving users who rely on them an opportunity to object and reconsider the soft-fork. The discussion continues on the bitcoin-dev mailing list, with different perspectives and suggestions being put forward.