I'm missing something from this discussion. Is this an academic exercise or are there scenarios that don't work well with things as they are? It's hard to determine if a suggested change solve the problem without knowing what the problem is.
Here's a problem: I find it annoying that in some (other) languages there's no easy way to trap integer overflow. It's easy to write code that's wrong accidentally. But changing the language definition to fail when an overflow happens would break some valid programs. In python, results that return nan or inf aren't exactly silent failures but they are quiet. (Personally, I would have made them non-hashable so you couldn't accidentally stick one in a dict but that's another problem.)
Anyway, of silent/quiet failure is the issue, then what we need is a way to make the failure not silent, e.g., wrap it in a try/except block like this that says, convert any nans to NanErrors:
try with NanError: blah except NanError: blah
Inside this scope, it might be useful to run code that does allow nans, which means we'd also need something like:
without NanError: blah
This all seems a bit too magic in how it would work. This is along the line of Mark Dickinson's suggestion, but the default behavior should stay the same as it is now.