Thank you so much! 
It really depends. Since 2023.2 came out, we have been actively watching translations come in and have scheduled releases just to get more translations in because we knew the new and changed strings were disruptive. Typically we only update translations when we already have a release planned or when a community member specifically requests a release. There are times where this would be hard to accommodate but so far we have always been able to honor those requests.
This is really great to hear, thank you for that feedback. Another option that you could consider is to leave the location question as non-required. If it is left blank, you could ask a question like "The location was left blank. If you need to send anyway, explain why." This text field could be required. Then the user could fill in an explanation if something unusual happened like their phone wasn't getting a location at all. If they don't supply an explanation, for example because they just need to step outside and try again, the form would not be finalize-able so they would have to save as draft. There are lots of variations on this approach including using one or many select questions instead of an open text box.
I see, that makes a lot of sense and explains why staying on 2023.1 is a better option for you at this time. We will consider that as we think of longer-term options.
Thank you, these are on our radar. We don't have a timeline for them yet but we know that they're important.
Yes, this has potential! There are interesting questions around what the experience should be when finalization fails and around how bulk select should be accessed.
Thank you so much, this provides so much valuable detail!
I see that you make use of the search() appearance function. This is indeed not supported by Enketo and also not included in ODK docs (though it's in xlsform.org and still maintained for now). The alternative functionality that works in both clients is select_one_from_file.
The only downside is that the performance for select_one_from_file hasn't fully been optimized yet and it can become slow for very large attached datasets or complex queries. I see you have 10k items in one CSV and 35k in the other. I haven't tried your specific form yet but we generally test with 60k+ items with no performance impact on modern devices. That could be an option to consider if you do want to try server-based edits. We also maintain Enketo and have made several performance improvements recently which you can try out at https://getodk.org/xlsform/ (Kobo and others that use ODK clients often run older versions).
It sounds like your scenario is quite similar to @seewhy's. Your data collectors are motivated and trusted, the data they are collecting is largely objective, and the thing that you're collecting data about is largely unchanging in a short time frame (as opposed to e.g. someone's health). It is possible to make honest mistakes and then it is desired to revisit the environment and fix those errors.