How text is stored in the indexes and queried is determined by a Lucene Analyzer (see this good summary article), and by default ModeShape uses a StandardAnalyzer. So you could choose a different analyzer if one better suits your need, but doing so affects the whole repository.
JCR has very limited support for localized properties: there are some built-in mixins and property definitions for storing locales. But that's about it. There is currently no way to specify locale-specific ordering or comparison. However, we are using Comparator implementations (which just use String equals and compareTo methods, and thus completely unaware of locales) within our sorting and comparison operations. This can be corrected: it's really just a matter of figuring out a way to client to supply the desired locale (e.g., via something like what you mentioned above), and then adjusting the engine to use a Collator for that locale. It seems deceptively simple, because we'd have to change lots of signatures (to pass the desired locale) of lots of methods used in the preparation of the queries. But it's probably worth doing.
Feel free to log an enhancment.
Thanks, I've created MODE-1727 to cover this.
A way that affect the whole repository doesn't really work for my usecase as the locale used should be that specified by a particular user in a particular session and may even be changed during the session if the user wants to (unlikely but possible). That said, I will look at that as a possible short term solution in our first release where a server installation probably only uses a single locale setting, not user selectable.
This is not a show stopper and for us is probably not first release functionality, I'm just covering the bases to make sure we can do this in later releases without too much rework. Internationalisation can be a trap if not considered early on, it gets harder to retrofit the larger your code base grows.