You may be considering of legitimate but non-standard transactions. From the perspective of the node software program:

Standardness is what kind of transactions ought to be included.

Validity is what kind 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 embrace it in candidate blocks for mining, even whether it is legitimate. Nevertheless, if it sees non-standard but legitimate transaction has been confirmed on the chain, it’s going to settle for it.

Bitcoin Core and and Bitcoin Knots have a barely totally different perspective (coverage) on standardness, however agree on validity. If nodes had been to disagree on validity, there would possible be a fork.

…how will it’s backwards suitable?

It may be price taking a look at OP_CHECKSIGADD for an instance opcode solely utilized in Tapscript.

case OP_CHECKSIGADD:
    {
        // OP_CHECKSIGADD is just obtainable 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 right now with a assist of a miner?

No, the script could be invalid. Such a transaction, and its block, could be rejected as invalid by all nodes operating a Bitcoin Core model, or derivation, launched since OP_CAT was eliminated (i.e. ~all of them).