It also gets quite clever with detecting repeated formatting. Just like Word can notice when the part up to a colon of each enumeration item is bold and does this automatically, it can notice that the second column of a table is always the same language and can even change the keyboard layout accordingly. But overriding the language once for everything should stop all that, still.
I just encounter countless broken programs that don't really support that distinction (e.g. Chrome ignoring date/time formatting settings in its UI since UI language and locale are being conflated, some applications trying to guess the UI language based on the locale or even the keyboard layout (what thought was behind that, I cannot even guess). It's a mess, but mostly on the application side and probably because lots of cross-platform applications don't even know there is a distinction on some platforms (and gettext not knowing about UI language and thus using locale doesn't help either).
When I was working on a host where I needed two layouts (US-Dvorak + US-Qwerty for other users) I ended up solving the problem using AutoHotKey to hook all keys and send a different keyevent. It was pretty gross but it bypassed all the issues I was having in a convenient way.
Perhaps you could hook US symbols such as "$" and rebind to UK equivalents with AHK? Alternatively, creating a modified EN-US keyboard layout which has relevant key-symbols would also work / be less hacky, but probably require more effort.
Microsoft Office, if anything, has gone completely backwards in regards to UX. On a fundamental level it 'just works' but when I started becoming more of a power user I found reproducible bugs, unexpected or inconsistent behaviors, and a complete lack of extensibility for creating / modifying docx documents programmatically in !C#.
By far my least favorite issue is the constant battle I have with locale - I'm not sure if the document creators local was set to EN-US or if my system config is not correct, but every time I try and force the document to EN-AU it seems to switch back seemingly on a per-section basis or something. The most amusing side effect of this is the 'Read aloud' voice changing gender mid sentence but the amusement is quickly offset by it deciding to auto-correct perfectly valid EN-AU spelling for its American localisation for the fifth time in a paragraph.