And for example, given that Taproot was implemented without a hard fork being required, a patch could be pushed to disable certain OP codes until they can be re-implemented later with proper spam filtering.
Do you understand implication of disabling opcodes used by ordinals? Ordinals use OP_PUSHDATA and OP_PUSHBYTES which is used for various thing such as multi-signature and HTLC for Lightning Network. Your suggestion would kill Bitcoin popularity.
you dont have to choose between fully open unlimited byte opcodes. vs disabled opcode. you can have conditional opcodes too
there are many methods
EG if old nodes only understand the ruleset of opcode conditions from blockversion 3 then treat opcodes that have no conditions as
"if block version>3 treat as 'isvalid'. else reject"
thus they are treated as disabled when blockversion was 3 but allowed to pass now the blockversion is higher
whereby when upgrading new functionality/tx formats requiring a blockversion 5. the opcodes have a byte limit in the code for specific functionality checks and validation of a new feature where if new open opcodes are added they too have the condition
"if block version>4 treat as 'isvalid'. else reject"
thus they are treated as disabled while blockversion is still 4 but allowed to pass if the blockversion is higher
(i know version utility is not as said. its a demo of how opcodes can actually be coded to have conditions)even now we can make code(because bitcoin relies on code) that from blockheight 840k opcode pushdata4 now has X byte limit
That's great idea. Although since BRC-20 dominate Ordinals TX, condition by bytes limit or range alone wouldn't work since BRC-20 TX have very small bytes and there's trivial workaround where the software pad BRC-20 data with zero/whitespace.