There are 2 pairs of chevrons in Unicode: U+27E8 U+27E9 and U+2329 U+232A. The latter are deprecated and have wrong width. (Scroll down to the end of the section.)

When I put the good chevrons in my configuration, wrong chevrons are actually bound by the generated X Keyboard Extension files.

My source looks like this:

    ...
    { "pos": "8", "letters": [ "-", "8", "−", "\u27E8" ] },
    { "pos": "9", "letters": [ "/", "9", "÷", "⟩" ] },
    ...

The generated symbols file looks like this:

    ...
    key <AE08> { [        minus,            8,        U2212, leftanglebracket ] };
    key <AE09> { [        slash,            9,     division, rightanglebracket ] };
    ...

Why leftanglebracket and rightanglebracket denotations are expanded to the obsolete pair of chevrons is a question in itself, but I have no idea where to post that issue. A solution that works for now is to denote the desired symbols by their Unicode numbers, like this:

    ...
    key <AE08> { [        minus,            8,        U2212, U27E8 ] };
    key <AE09> { [        slash,            9,     division, U27E9 ] };
    ...

Every time I regenerate the files, I must patch them again, so this is not a long term solution.

How should we approach this problem?

1. I propose that we find the upstream of the symbolic ...anglebracket denotations and ask them to put forward an update. By chance you have a suggestion who that might be? The xkbcommon people?
2. In the meanwhile, a temporary fix could be put in place. We may emit the Unicode numbers for the chevrons instead of the symbolic denotation.
3. Possibly we could give the user the power to decide whether to prefer symbolic or numeric denotations? Although I am not sure how that may look ideally, but as a first approximation, a switch to emit numeric denotations exclusively may be good. Actually, is there any reason to emit symbolic denotations, beside human readability?