The existing CScriptNum is presented as a tried-and-tested solution that is already in use, suggesting it would be advantageous to build upon it rather than introduce an entirely new number format. The compactness of the current minimal-length big-endian representation within scripts is highlighted as a benefit, especially when compared to a hypothetical fixed-size little-endian alternative which might compel developers to frequently convert between formats, potentially hindering a smooth transition to a larger bit-sized number format.

Further discussion acknowledges that while there may be edge cases concerning the use of CScriptNum with 8-byte values, a proposed solution by @sipa appears straightforward, as demonstrated in the provided commit link: https://github.com/halseth/bitcoin/pull/1/commits/13c1848edf66410517b3cb6d47d80874438abb1f, which extends 64-bit support across various numeric opcodes. Additionally, the availability of leaf_version from the interpreter is noted, indicating that defining a new version should be relatively simple.

The conversation also touches on potential issues related to overflow detection and handling if multiplication opcodes like OP_MUL are reintroduced. Ensuring that these opcodes are backward compatible with the existing number format (alongside a leaf_version update) is emphasized as an ideal approach for re-enabling them. The overall tone suggests a preference for enhancing the existing infrastructure rather than overhauling it, balancing the needs of current developers with the system's growth and evolution.