It's a fairly long-standing principle of PPCG that languages are defined by their implementations; in other words, the language specification is entirely ignored, and we look at the behaviour of an implementation in practice to determine how the program works. This means that if no interpreter can run the program (e.g. because existing interpreters are buggy), the program can't be submitted at all.
It's also a fairly long-standing principle of PPCG that submissions should work on all possible inputs (even if the corresponding output would be far too complex for a system to print, or far too large for a computer to be able to store); and on the flip side, submissions are commonly so inefficient that they couldn't possibly run in practice even on fairly small inputs. (For example, a program that uses O(22n) time or memory would typically be considered an appropriate submission.) As such, submissions tend to be verified not by using test cases (which would be impossible for most challenges, as they accept an infinite space of possible inputs), but rather by giving a proof that the submission would work (or even more indirectly, by challenging people to find a counterexample and assuming the answer is correct if nobody can find one).
However, there's something of a contradiction here. We're starting off by saying "following the specification is not enough, you have to run the program to prove it works". Then we're saying "it's OK if the program can't actually run in practice, just so long as it could run in theory if you had an infinitely powerful computer". From my point of view, it doesn't make sense to have these rules at the same time; we could have either individually, but the combination is problematic. We have a rule that language specifications aren't relevant – and yet people repeatedly resort to them in an attempt to demonstrate that their program works for all input (because trying to prove facts about a language implementation is almost impossible in practice unless using a certified compiler, as the implementation tends to be much more complex than the specification). We have a rule that languages can't exploit their own limited integer sizes to simplify the problem – and yet we define the behaviour of the language on those integers via observing what the implementation does, and it doesn't.
How can we reconcile these rules to be more compatible with each other?