A few thoughts on this. First of all, you say "the cmd+v shortcut is a key-binding rather than a letter-binding". That can't be true: For example I can switch to Dvorak, which is an alternative English layout where 'c' and 'v' are assigned to other physical keys. And then of course I'd expect cmd+v to work with that new 'v' key and not the old one (which types 'k' on Dvorak layout). And that's exactly what happens in OSX.
Anyway, I can reproduce your problem with hebrew and I can confirm that other OSX apps get this right, but JUCE apps don't. And here is the reason for it: juce_TextEditorKeyMapper.h:96
if (key == KeyPress ('v', ModifierKeys::commandModifier, 0)
|| key == KeyPress (KeyPress::insertKey, ModifierKeys::shiftModifier, 0))
So yes, it does look for the character 'v' and not any physical key (the insertKey is something else).
But then how would I even fix this? It would need to be smart enough to know when to look for the key (e.g. in Hebrew, Russian, Arabic...) and when to look for the character instead (e.g. in Dvorak, Colemak...).
This becomes even more complicated if you consider other key commands like, for example, cmd+z for "undo". On a German keyboard, 'y' and 'z' are swapped. So again you would not look at the physical key but at the character (whereas you would still have to look at the physical key if you're on Hebrew). Likewise, 'q' is on another physical key on the French keyboard layout (cmd+q for "quit") etc etc. All those commands would instantly break if I change the code to look for the key instead of the character.
This seems very complicated to get right and doesn't sound like something we could easily do in JUCE (consider effort vs. benefit). The current behaviour seems a lesser evil to me than going down that path (i.e. it currently works correctly with all keyboard layouts that use latin characters). Unless maybe there is an API somewhere that already solves all those problems and that we could use instead?