As with all Windows applications behavior of the AltGr key for IME depends on the physical keyboard, the keyboard mapping selected, and only then how LibreOffice handles the generated keycode.

For locales where AltGr is used, os managed keyboard mapings will generate AltGr keycde, and for keyboards that do not have a physical AlgGr, the keyboard mapping Microsoft chose to send <AltGr> is a <Ctrl>+<Alt>.

That mapping is triggered by the os, when for example the us-international rather than the us keyboard mapping is selected by the user. 

Users could force their keyboard selection to *not* generate the AltGr, i.e. change keyboard to US, rather than US-International, and LibreOffice would behave.

Unfortunately that is not realistic... bug 95761 implemented a first attempt at allowing for use of both by splitting function <Left Alt> and <Right Alt> and allowing the <Right Alt>+<Ctrl> to be available as the <AltGr> for keyboard mappings/locales that required <AltGr>. But flolks did not like it--though it was technically sound.

A more nuanced solution for Windows builds would require we:

1. detect os assigned keyboard layout 
2. detect physical keyboard --parsing of GetKeyboardLayout() call?--
3. confirm os assigned locale

Then, test for AltGr physical key. If the <Right Alt>/<AltGr> key is not physically present (physical keysym or os mapping), <Ctrl>+<Alt> keyboard shortcuts will cause problems--remap dynamically? 

Could maybe make use of a MOD3 assignment to <Right Alt>/<AltGr> in shortcuts by locale/keyboard, similar was done for macOS <Cmd> shortcut collisions.

Believe in general the Linux builds are not much affected here, and all reported issues have been Windows os builds. 

But, guess some of the IME & deadkey mappings are impacted by physical keyboard and os mappings of the <AltGr> key.  And then there are issues with some of the stranger physical keyboards and os mappings--the Apple Touchbar keyboard on macOS, bug 105803 as an immediate example. But other locale specific mappings and physical keyboard layouts mean chasing these keyboard mapping issues one at a time is always going to be a partial solution.

jmux comment on the topic http://document-foundation-mail-archive.969070.n3.nabble.com/Re-Libreoffice-qa-minutes-of-ESC-call-tc4248679.html

(the issue is not limited to Windows)

(In reply to Heiko Tietze from comment #2)
> jmux comment on the topic
> http://document-foundation-mail-archive.969070.n3.nabble.com/Re-Libreoffice-
> qa-minutes-of-ESC-call-tc4248679.html
> 
> (the issue is not limited to Windows)

This patch acceppted?

@:V Stuart Foote
This problem would be resolved (forever), if combination of Alt+Controll (AltGr) and Alt+Controll+Shift (AltGr+Shift) would be exclude from all hotkey capabilities on Windows.
In this case must be remap the hotkeys (or called accelerators).
I have no rights to develop for all languages, I think.
In the other words: discussion needed.
Thanks.

(In reply to V Stuart Foote from comment #1)
> 1. detect os assigned keyboard layout 
> 2. detect physical keyboard --parsing of GetKeyboardLayout() call?--
> 3. confirm os assigned locale
@:Stuart Foote
Detecting phycical keyboard with GetKeyboardLayout() is a good idea --for detecing alternative layouts. This determine the layout with a double word size number, if the highest bit is set, the layout is an alternative layout, like Old Hungarian layouts.
Is it possible to switch out accelerators temporarily, when detect the active alternative layout?