I agree with your take and want to add that "we want less CVEs" and "we want meaningful rewrites" are not necessarily at odds with each other. We can have both.

I'll also note that efforts like rewriting a lot of UNIX userland in Rust also introduces the benefits of rewrites -- you have to think super hard if you want that obscure command-line switch that only works in X way if another switch has another value or it does the thing Y if two other switches have these other values. I forgot the examples but that's what happened there: people figured "we will not implement command switches X and Y" and lo and behold, people using those tools never even noticed, myself included.

So, rewrites have positives as well. And not everyone doing rewrites is clueless.

I didn't say that those who do rewrites are clueless. I said that rewrites are really hard - far harder than most people expect.

That weird switch behavior? I almost guarantee that someone, somwhere, some when depended on that behavior. Either they no longer use the switch behavior or they no longer use the tool, or they just don't use the rewritten version. But how do you know that? In the best case, the code would have a comment: "This code is to simulate Berkeley 3 behavior for users porting from..." But even that doesn't tell you whether anybody today still depends on it.

I mean, it could be a valid strategy to not rewrite weird behaviors - any of them - and see what breaks, and then only add the ones that are still needed. The upside is a much cleaner rewrite, with fewer (and, hopefully, better documented) weird behaviors. The downside is that you have to break stuff temporarily to find out. (Hopefully you break it in live staging rather than in production...)