https://bugs.winehq.org/show_bug.cgi?id=53778
--- Comment #1 from sloonz@gmail.com --- Found the issue.
To translate a WM_KEYDOWN / WM_KEYUP event (virtual key & scan code) to a WM_CHAR event, the X11 driver loops over all keycodes, finds what virtual key would generate that key code, and if there's a match, generate an X event to look at the associated string (https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/winex11.drv/keyboard....).
But there’s actually two keycodes that can generate the VK_DELETE virtual key : the one associated with the actual delete key, and the one associated with the keypad delete. For us keyboards, it is actually correctly handled by translated a KP_* keysym to the correct virtual key (https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/winex11.drv/keyboard....).
Unfortunately, as can be seen in xev, bepo keyboard gives a "." keysym for keypad ".", not XK_KP_Separator, leading to the described incorrect behavior. A cursory glance at /usr/share/X11/xkb quickly shows it’s a mess here, with the keypad delete key can be associated with either ".", ",", XK_KP_Separator or XK_KP_Decimal, depending on (if I understand it right) udev rules (?!)
Not sure how it can be fixed on Wine end, or if it SHOULD be fixed on Wine end.
Anyway, I solved it on my end by adding a kpdl(comma) option to the XKB configuration, forcing it to send a XK_KP_Separator keysym.