My concern is less about introspection and more about adding features in L1 that future L2s may not need, to keep the EVM as “modular” as possible.
Adding opcodes that reflect Ethereum’s specific consensus algorithm create baggage that other “ethereum equivalent” L2s have to manage. Some are obvious, such as how to handle blobs in a L2 that doesn’t have sub-blobs: return zeros and otherwise handle the block like there were no blobs.
What we are doing with the beacon block root I think is the better way forward: surface it in the contracts instead of altering the VM when a new consensus feature is exposed. L2s that don’t have a beacon block root don’t then have to alter the EVM to remove or alter an opcode.