It's a typical problem when there is no primary documentation of a protocol and all you have is a reference implementation (Bitcoin Core). This means that you have to embrace "it's not a bug, it's a feature".

Every "competing" implementation, as you point out, is just a rewrite, that has to replicate all the "bugs" and warts in itself.

It should be pointed out that one of the reasons why all the arithmetic operations in Script had to be disabled is because different compilers and platforms could behave differently in some edge cases (like integer overflow), and lead to exploits or undefined behaviour.

I dare say, if Bitcoin Core were written in something like Rust, those might still be available today (Rust is much more consistent across targets), but not so much in C. The consequence being, even if you rewrote it in Rust, you couldn't reenable them because that's no longer part of the consensus, it's just dead opcodes.

I would welcome with open arms an initiative to actually write down the consensus rules as a document (the white paper has very few details), followed by a complete test suite that is implementation-agnostic, which then could be applied to Bitcoin Core and others as a proof of their validity.

At this point it would be clear what is a bug and what isn't.

(Yes, Bitcoin Core has a lot of unit tests but they are tied to that implementation only. I'm talking about "end-to-end" tests - you input a blockchain state and a new block and test whether program accepts it or not.)

In fact, for something that wants to be the "money of the future" or the "operating system of value", I'm shocked something like that doesn't exist yet. We're really running on software engineering hopium here.

In modern software development this is how we do things now (Test-Driven Development) but unfortunately Satoshi gave us what we would now call "legacy software".