Concerns are raised about the complexity this change might introduce and its possible encroachment on the available opcode space within Bitcoin's script system. Despite these concerns, there is a clear distinction that skepticism does not extend to expanding arithmetic support from the current 51-bit support to 64-bit.

A key point of contention is how such changes would be compatible with existing version 1 tapscripts, considering the risk of breaking scripts that are already in use. To mitigate this risk, the proposal includes the introduction of an OP_ENABLE64BIT opcode. This opcode would act as a flag, enabling all subsequent arithmetic opcodes within the same script to accept up to 8-byte inputs without affecting current scripts, as they would not contain this new opcode. The presence of OP_ENABLE64BIT in a script would not impact its validity under current consensus rules and would maintain compatibility through a soft fork approach because scripts containing the opcode would still be considered anyone-can-spend by existing standards.

An alternative solution proposed is the creation of a new taproot leaf version, which offers a more compact approach to implementing these changes. The new taproot leaf version would delineate scripts that are capable of handling the expanded arithmetic capability, thereby avoiding any disruption to pre-existing scripts.

In summary, while there are reservations about the potential complexities of changing encoding formats and expanding opcode utility, there is an open-mindedness towards enhancing arithmetic operations within Bitcoin's scripting capabilities. The solutions offered aim to ensure backward compatibility and network stability, emphasizing the importance of a careful and considerate approach to protocol evolution.