Warn initially (few versions) and then raise exception/critical errors after. If developer isn't willing to update, chances are server isnt being updated either anyways.
(I say do it anyway. It's like IE6; give it a long grace period, then tell people they need to get with the program.)
Imagine a language runtime in which arithmetic on exact multiples of 1536 always returned -1. You could work around that if you had to, but it would be awful. You'd have to scrutinize most every line carefully to rule out this ever happening, or wrap every numeric subexpression in some kind of conversion to/from safe values, which nobody would be consistent about doing. The maintenance difference between clear, expressive code and code that actually works would be dramatic. People would tend to realize it started happening again a while ago and rush to fix one spot in production that seems prone to it. The web would be littered with tutorials that punt on handling it in the name of encouraging beginners.
Then there's idiocy like "break 2" which is worse than goto in every possible way yet more widely supported.
If you have a choice, sure, don't use PHP. But if you don't have a choice, PHP won't stop you shipping a quality product.
I have switched from php long ago, but remember odd naming conventions and frequent switch of parameters.