Thanks for comments - appreciated.
I agree this is a 2.0-y feature, but on the other hand, it doesn't break anything for language translators as all existing language files will continue working. (Even if the English language string uses this feature, you don't have to use it in the French one.) So it doesn't 'require' a lot of work - it just gives you the option to do a lot of work if you want to improve the grammar of the translation.
It also doesn't break any code that calls get_string, or any existing language strings. So it's the kind of change that might be technically feasible in a 1.9 update - especially if the 1.9 branch is very long-lived. But if it were to be backported from 2.0 to 1.9.x, that would be a decision for later anyway.
As you can tell I originally wanted to do this feature for 1.9 because we are on 1.9 here and people were complaining to me about the (English) grammar. But at this point we are about to release based on a 1.9 beta and I have already told them to shut up. So it doesn't matter too much if the feature never makes it into the 1.9 branch.
As for local customisation I think that would be ok as it only gets slightly more complicated:
1) I think this feature will only be used for a few strings at least at first. So if you aren't trying to customise one of those strings then you don't have to worry about it (or even see it).
2) Even if you do want to customise one of those strings, if you're in the same language probably you are not going to want to change the PHP expressions, so as long as you don't mess with these it will be ok to just leave them and edit the two strings.
3) This does of course mean you might have to edit two strings where there was only one before (or understand to use the X button to get rid of the except-string in your local version).
I think there might be concern about usability overall though. Apart from that, I didn't write any changes to the help to actually document it, which it surely needs!