In my opinion (which may be worth little), by using "git" in your product's name today you are also locking onto that technology. So if an another or better VCS comes along (like jj) that you want to embrace it could be harder. (Kind of like how Bitbucket betted wrongly on hg, then later added and switched to git).
More issues generally arise from supporting/qualifying older OS versions than supporting specific architectures in my experience, so developers keep around older hardware or VMs for that purpose. In some other circumstances Rosetta may not be sufficient for testing older Intel hardware (one example is work on GPU)
For updating bookmarks I've found like half a dozen variants of `tug` alias the community has come to using which is just a slight improvement (bit daunting to newcomer to pick 'best' one and not fan setting up aliases on all my working devices).
It would be nice if jj was better than git for the fundamental workflows like this out of the box overall.
Just my feedback - I've personally found jj more complex for simple projects. Like if you have a non-collaborative repo where you push to main most of the time after making a series of commits, in jj you have to keep updating a bookmark before pushing it and there's no one command to do both.
If you have another machine on main without any outstanding changes and you want to pull the latest changes that is probably also two steps (git fetch + new?)
That said, I've been liking jj quite a bit for more mature / collaborative projects. It has been a learning experience. (don't enjoy updating bookmarks for PR branches though; jj encourages rewriting history which is not my favorite choice for code review branches; I often work in repos that squash-on-merge).
Applications may have permission to access files/services that other apps and even root (I believe) would need user-prompt access to, gated by TCC (potentially including sandboxed game’s data).
Code signed games that opt into enabling library validation should prevent the issue of loading arbitrary code, however many games likely don’t do this.
I had a small server written in Haskell but since the other contributor familiar with Java/C/C++ was not able to pick at it effectively, we switched to Rust and we all were happy, and transitioning was fine.
At work I deal with Java code, but we have a framework we wanted to use that's written in Scala, and since Scala can interop with Java, we were all productively able to transition over for the better.
For a hobby project we use Objective-C, but we are starting to write some bits in Swift. Apple is especially effective at trying to convince the developers to change over to this shiny language.
I think "advanced" languages can be used in real world applications, and the transition experience from other well known languages can certainly matter.