Would OP_SUCCESS (OP_CAT) be spent?

The discussion revolves around the nuances of censorship within the Proof of Work (PoW) framework and its implications for Bitcoin's ecosystem. Specifically, it debates the acceptability and consequences of certain types of transaction censorship enforced by miners, contrasting this with the role of oracles in enforcing specific behaviors. The conversation delves into the technicalities of Bitcoin scripting, citing examples such as OP_2DROP OP_CHECKSIG being enforceable by oracles versus OP_NOP10 OP_2DROP OP_1, where OP_NOP10 serves as an ad-hoc, opt-in mechanism akin to OP_CHECKPROGRAMVERIFY. This distinction raises questions about the legitimacy and potential concerns surrounding miner-enforced censorship based on very specific patterns that users opt into.

The inquiry further explores whether such arrangements—where miners signal their intent to censor transactions not adhering to a particular program's hash—are acceptable or deemed an attack on Bitcoin's integrity due to the lack of broad ecosystem agreement. It highlights the critical role of miners and a minority of users interested in specific use cases in reaching consensus on these matters. Moreover, the question implies a comparison with the risks associated with trusting oracles and whether the scarcity of OP_SUCCESS codes presents the only significant issue with employing OP_SUCCESS126 for such purposes.

Additionally, the discussion acknowledges the potential repercussions on other miners and the necessity for them to respond, similar to their reaction to an OP_SUCCESS soft fork, suggesting that the broader ecosystem might not need to be involved in such decisions. This discourse invites further examination of how oracle-based emulation, as exemplified in the provided GitHub example, could offer insights into more acceptable forms of script enforcement and censorship within the Bitcoin network.