The problem is that if you did that then you couldn't check regular C programs anymore, since overflow would be valid. Right now we're in the nice situation in which normal C programs are expected not to exhibit signed overflow. Change that state of affairs and suddenly a lot of obvious mistakes become valid.
The problem is that if you did that then you couldn't check regular C programs anymore, since overflow would be valid.
That also means it's possible to write overflow checks easily, and ones that the compiler won't optimise out. Before compilers became UB-crazy, you could write such checks in the most straightforward way, and get exactly what you expected. I'd consider that a far bigger advantage for security than arguing for the existence of a tool whose sole reason for existence seems to be due to the presence of UB in the first place.
You could always say that wrap-around has to either (a) cause SIGILL or (b) return the wrapped-around result. That still allows linting with a sanitizer without involving any UB at all.
This is effectively what Rust does (replace "SIGILL" by "panic").
As far as I can tell, signed overflow is undefined behavior because when the standard was defined there were a lot of machines where it would trap or do something weird, and for some reason the standards authors did not choose to make it implementation-defined behavior.
You could always write “WrapAroundSan”.