The debate includes considerations of system accessibility for newer developers who might find the current numbering system in Bitcoin confusing due to their experience with more universally applied rules in software development, such as fixed input sizes. The proposition under scrutiny suggests modifying CScriptNum to support 64-bit numbers, but this raises concerns about consensus risk for pre-existing Scripts.

An alternative is presented which leans towards an encoding that enforces an 8-byte standard for literals without raising malleability issues, as this size would become mandatory. This proposal could entail creating new opcode variants to distinguish between different byte sizes or introducing special logic to handle the variable byte values depending on the version of the witness or leaf. However, the intricacies of implementing such changes are acknowledged, especially given the advice against altering CScriptNum due to the difficulty in predicting its behavior impact on consensus. The conversation also touches upon the endianness preference, weighing the merits of big endian over the typically used little endian, despite the latter's prevalence in other parts of the protocol.