Wouldn't it be great if all that english text in the language standard documents were enforced and/or exercised at both compile time and (dev) runtime?
Instead of just "dev" and "release", I would love to see the default be "evil".
As in... in "evil" mode the compiler will abuse every rule, randomise everything that is not explicitly specified, and run your code on a virtual machine that has 19 bit ints, 23-bit pointers, bizarre memory models, or whatever to make sure that your code is truly robust, not just "mostly robust", which is like being "almost pregnant".
For a real life example, there was a bug lurking in the Java standard library (and several other languages!) where "sort()" wouldn't work on maximum-length arrays because they used the naive (a+b)/2 algorithm to find the mid-point of a segment and hit an integer overflow.
If there was an evil runtime with tiny integer sizes, they could have hit this with small array sizes and realised their mistake early instead of shipping broken code that blows up and crashes on the biggest and hence most important servers in the world... sometimes.
Taken to the n-th degree, haven't you wondered how many similar bugs lurk in standard libraries? Which "algorithms" work on max-length arrays? Which only work on MAX/2? Which on MAX/4? Which on (MAX/8)-53? Who knows! I don't. You don't either. Some or all of these could blow up in your face at the worst possible time and you have no way to test this[1].
An evil VM could be devised to test things like:
"Throw any exception that could be triggered a small percentage of the time, or at command".
"Pretend memory is far more constrained than on the specific physical host where the code is being developed."
"Introduce network latency, UDP packet reordering, random packet drops, and every possible IO error that the host operating system might throw."
"Use a different memory consistency model to the current physical CPU."
"Pause threads randomly, and otherwise randomize timing and interleaving behaviour to the maximum extent allowed by the spec."
"Simulate processors with different bitness, such as combinations of integer size vs pointer size."
"If the spec doesn't require any particular boolean representation, then run the code with different ones randomly. E.g.: 1, -1, and even random non-zero values for true."
"Database queries that don't specify the sort order are often returned reversed or randomized."
"i18n settings that aren't explicitly specified are randomized. Your UI language is Turkish, the keyboard is French, and the region is Japan."
"All external environment variables are randomized and/or substituted with similar but potentially invalid values. You must explicitly specify the whitelist of environment variables that you require to be stable."[2]
[1] Except for running code intended for 64-bit in 32-bit mode and testing with 2-4GB data sizes. However, there are other potential issues for which such tricks don't work. Anyway, this is just a "poor man's evil VM". What you want is a full flexible evil VM that can constrain anything.
[2] Sounds like a pain in the backside for you? Now put yourself in the shoes of the poor admin that has to make this stupid thing work from a compiled binary 17 years later and has to reverse engineer the possible environment variables using a hex editor and a glass of scotch.