OK. Do you have any examples of a modern version of MySQL or InnoDB doing this?
> how many people have avoided upgrading to 5.7 because of this change
As I said, 5.7 just changed the default. This setting has been available since mysql 5.0.2 in early 2004 -- it just wasn't the default. Or you can use 5.7 and override the new default to get the old unsafe behavior. This change is absolutely a non-issue in terms of avoiding upgrades.
> other issues regarding the new revamped query planner which makes software like Zabbix slow to a crawl
I have heard of very few issues from the query planner improvements. Anecdotal, sure, but I am pretty "in the loop" fwiw.
> Ah, the old "it's not a footgun if you know better" argument.
How is that my argument? I directly said "I agree this could be improved to be less of a footgun for new users"!
The database won't force read_only for replicas because there are replication topologies (e.g. master-master) where nodes are replicating but also still need to be directly writable. These topologies are a bad practice (IMO) but nonetheless are used by enough places that MySQL cannot simply force read_only for replicas.
In any case, these days administrators who are completely unfamiliar with MySQL replication concepts should probably be using a DBaaS rather than setting up replication manually. The DBaaS platforms enforce read_only properly, making this all a non-issue.
Corruption in the sense of allowing data that is invalid ( clobbering valid data even on transaction error) is corruption by my definition.
>0000-00-00 will error upon insert by default since 2015
How many people have noticed they have invalid data only because of this change? how many people have avoided upgrading to 5.7 because of this change (and, admittedly other issues regarding the new revamped query planner which makes software like Zabbix slow to a crawl)... But, yes, it's a change in the right direction.
>MySQL replicas should be read-only
Ah, the old "it's not a footgun if you know better" argument.