bug#37530: 26.1; Tack characters translated incorrectly

[Eli Zaretskii <eliz@gnu.org>]

> From: Axel Svensson <mail@axelsvensson.com>
> Date: Thu, 26 Sep 2019 23:31:34 +0200
> 
> Press C-h l to run view-lossage.
> The last lines display the erroneous characters that were inserted,
> rather than the expected characters.
>  ⊣ [self-insert-command]
>  ⊢ [self-insert-command]
>  ⊥ [self-insert-command]
>  ⊤ [self-insert-command]
>  C-h l [view-lossage]
> 
> In order to confirm that the behavior I have stated as expected is the
> correct one, look to the XKB keysym definitions:
> > #define XKB_KEY_downtack                      0x0bc2  /* U+22A4 DOWN TACK */
> > #define XKB_KEY_uptack                        0x0bce  /* U+22A5 UP TACK */
> > #define XKB_KEY_lefttack                      0x0bdc  /* U+22A3 LEFT TACK */
> > #define XKB_KEY_righttack                     0x0bfc  /* U+22A2 RIGHT TACK */
> These can be found at:
> https://github.com/xkbcommon/libxkbcommon/blob/master/xkbcommon/xkbcommon-keysyms.h
> 
> It is understandable that bugs like these can go unnoticed seeing that
> these characters probably aren't part of any widely used keyboard
> layout. If this bug can be confirmed, and depending on what caused it,
> it might be beneficial to add the complete mapping from X11 keysyms to
> Unicode codepoints as automated tests. I'm willing to provide this
> mapping, including source references.

Isn't the output of "C-h l" evidence that Emacs actually received the
codepoints it displayed?  IOW, how do we know this is a problem in
Emacs and not in the keyboard configuration and/or driver software?

Thanks.