If there really was an issue there then you either need to file a bug and have them mainline a fix, or yes hack/shim a fix on top for your needs. Perhaps leveraging PATH precedence.
Questioning the use case and insisting that one doesn't actually _want_ to do a thing instead of allowing the user to control their own system is the quintessential Apple experience.
However most people, including me, and I'd venture most engineers too, would rather have a hardened system.
Funny, that's a quote I hear a lot in Linux Desktop ecosystems as well. I think it is just the nature of people so accustomed to a certain way of thinking that any other use case that comes along is automatically considered to be doing it wrong.
If Linux is going to get attacked for not having a single GUI, it would be nice if it weren't also attacked for having a repressive GUI monoculture. /s
But more importantly, it's the question whose laptop it is. I continue to think that the tools I build go to /usr/bin, because that's the way I like it. Apple is telling me I'm liking it wrong.
As for filing a bug with Apple - good one. Every single Apple dev considers radr:// a black hole, and the chance of getting a fix from Apple because of bugs filed (vs. Apple wants to fix it anyways) is slim to none.
Overall, Macs are more and more machines that want to prevent shooting yourself in the foot, at the price of less flexibility and access. This is a good choice for some, it's not a good choice for me. (And many other people who like hacking their machines)
Yeah, but there's a certain expectation that the tool that you have installed in /usr/bin is a certain version. There's a reason why tools like Homebrew generally do not overwrite built-in tools.
If you just replaced /usr/bin/python with Python 3, you'd probably break all kinds of things.
macOS used to be "Unix, but with a great GUI". It is turning into "iOS, but with a few command line tools".
Because it's my computer that I paid for with my hard earned cash, and I want to.
How far we have fallen.