The author does not once say that Pony's choice is a good one, only that whether it is a good or bad one should be settled by engineering consequences, and that there is no purely mathematical argument that precludes it.
I can't help but think it _is_ a bad idea, because it's easier to overlook a 0 appearing than a NaN. That argument isn't math, though.
Most integer representations have no space for such a value, so the only choices available to language developers are:
1. Throw an exception or otherwise consider it an error
2. Define the result to be 0 or 1 or some other integer value (0 being the only good choice)
3. Use a non-standard integer representation
Most languages opt for option 1, Pony chose 2, and I've never seen 3, perhaps due to it requiring so much software interference and precluding inter-operation with other languages.
Devil's advocate: why not a maximum integer like 18446744073709551615 or 9223372036854775807?
0 looks like a valid number, while 18446744073709551615 is an obvious NaN for any programmer looking at the output.
In some domains it might be. In others it might not. It's no more right or wrong in my mind.
I think the size of the integer needs to be considered in your thinking as well:
If you have unsigned 8 bit integers, the max value is 255, is that really going seem NaN? How about 127 for a signed 8 bit integer?
And, should the result of division by zero vary based on the bit size of the integer? That's a discussion unto itself.
That seems sub-optimal.