You is likely to be pondering of legitimate but non-standard transactions. From the viewpoint of the node software program:
Standardness is what sort of transactions ought to be included.
Validity is what sort of transactions may be included.
If a node sees a potential transaction as non-standard it won’t share it on the P2P community and won’t embody it in candidate blocks for mining, even whether it is legitimate. Nonetheless, if it sees non-standard but legitimate transaction has been confirmed on the chain, it should settle for it.
Bitcoin Core and and Bitcoin Knots have a barely completely different viewpoint (coverage) on standardness, however agree on validity. If nodes have been to disagree on validity, there would doubtless be a fork.
…how will it’s backwards appropriate?
It is likely to be value OP_CHECKSIGADD for an instance opcode solely utilized in Tapscript.
case OP_CHECKSIGADD:
{
// OP_CHECKSIGADD is simply accessible in Tapscript
if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
But when it’s a coverage, op_cat can seem as we speak with a assist of a miner?
No, the script can be invalid. Such a transaction, and its block, can be rejected as invalid by all nodes working a Bitcoin Core model, or derivation, launched since OP_CAT was eliminated (i.e. ~all of them).