I was able to reproduce this issue. After a little bit of testing, here's what I can say:
- This issue is unrelated to Yakuake. It can be reproduced by setting "`" as a global shortcut.
The same thing happens if I set "`" to be Dolphin's or Okular's global shortcut for instance.

- The key binding has to be "`" alone. "Meta+`" and "Ctrl+`" both work fine and don't cause any issues.

- The key that stops working isn't necessarily "4". For me it's both the "u" and "7" keys.

- When I switch to the AZERTY keyboard layout, the "è" character, which uses the same physical key as "7" in QWERTY is the one that I can no longer input.
And when I switch to Arabic, the "ع" character, which uses the same physical key as "u" in QWERTY is the one that stops working.
So in short, changing the keyboard layout doesn't seem to have an effect.

- Switching the keyboard model in the "Input Devices" section of the settings doesn't seem to change much.
I have tried three models so far:
"Generic | Generic 86-key PC", "Generic | Generic 105-key PC" and "Dell | Dell 101-key PC" and this bug exists on all three.

- Trying to type the characters "7" and "u" with a khotkeys custom shortcut to send "u" as keyboard input or trying to use "xdotool key 7" both don't work.

- I tried using Screenkey, which is a screencast tool to display pressed keys on the screen.
It showed "u" and "7" even though nothing was being typed. It is the same with xinput.
After using "xinput list" to find the id of my keyboard, I used "xinput test #ID" to monitor key presses on the keyboard.
It was able to detect when each key was pressed and released.
Here's a sample of the output before enabling "`" as a global shortcut:

key press   16 
7key release 16 
key press   30 
ukey release 30 


You can see clearly that the "7" and "u" keys were inputted correctly.
And here's a sample of the output after enabling "`" as a global shortcut:

key press   16 
key release 16 
key press   30 
key release 30 


System information:

khotkeys version: khotkeys 5.18.5-1 (plasma)
Operating System: Manjaro Linux 
KDE Plasma Version: 5.18.5
KDE Frameworks Version: 5.70.0
Qt Version: 5.15.0
Kernel Version: 5.7.0-3-MANJARO
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz
Memory: 3,8 GiB of RAM

This is my first time trying to contribute to the KDE community. I hope this helps someone more experienced than me figure out the root cause of this bug.

If you run xev and press the key do you get FocusOut FocusIn events? If so it is possibly the same as bug 310881, bug 401806, bug 402913, bug 422329 for example. I think there are a few more out there with this problem.

Yes, I do.
Here's the output when I press a key that works properly like "6":

KeyPress event, serial 40, synthetic NO, window 0x5000001,
root 0x133, subw 0x5000002, time 4915810, (43,64), root:(43,93),
state 0x10, keycode 15 (keysym 0x36, 6), same_screen YES,
XLookupString gives 1 bytes: (36) "6"
XmbLookupString gives 1 bytes: (36) "6"
XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x5000001,
root 0x133, subw 0x5000002, time 4915874, (43,64), root:(43,93),
state 0x10, keycode 15 (keysym 0x36, 6), same_screen YES,
XLookupString gives 1 bytes: (36) "6"
XFilterEvent returns: False



And here's the output when I spell a key that doesn't work such as "7":

FocusOut event, serial 40, synthetic NO, window 0x5000001,
mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 40, synthetic NO, window 0x5000001,
mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 40, synthetic NO, window 0x0,
keys: 51 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

KeyRelease event, serial 40, synthetic NO, window 0x5000001,
root 0x133, subw 0x5000002, time 4693354, (33,32), root:(33,61),
state 0x10, keycode 16 (keysym 0x37, 7), same_screen YES,
XLookupString gives 1 bytes: (37) "7"
XFilterEvent returns: False



Thank you for looking into this.

I am not 'looking into this', I don't have a build environment ready for KDE and haven't written a single line for KDE. I am just providing help for the analysis.

Do you have multiple keyboard layouts set up? If so can you still reproduce the bug if you only leave one keyboard layout configured?

(In reply to Henning from comment #4)
> I am not 'looking into this', I don't have a build environment ready for KDE
> and haven't written a single line for KDE. I am just providing help for the
> analysis.

I'm sorry if my meaning didn't get across well. English is my third language. By 'looking into this' I did not mean fixing this bug. I just meant it as in trying to pinpoint the cause of the bug with us and providing suggestions. Sorry for the confusion once again.

> Do you have multiple keyboard layouts set up? If so can you still reproduce
> the bug if you only leave one keyboard layout configured?
Yes, I have three. And it depends on the one I leave:
If only leave English or Arabic, the issue is not reproducible.
If I only leave French, the "7" key doesn't work.
While trying this, I noticed something interesting which was that if I move Arabic up to the top of the list of layouts, the "u" key works properly, whereas if it's it's in the second or third spot, the "u" key doesn't work.
With French, as long as it's a configured layout, the "7" key won't work, no matter its position in the list of layouts.

So I had a little bit too much time on my hands and I may or may not have gone through all the layouts one by one to see which keys each one broke.
Anyway, here's the list.
These layouts cause the character "1" to not display properly:
ir Persian

These layouts cause the character "7" to not display properly:
>fr French,
>tg French(togo),
>al Albanian,
>me Montenegrin

These layouts cause the character "v" to not display properly:
>al Albanian,
>ba Bosnian,
>me Montenegrin,
>si Slovenian

These layouts cause the character "u" to not display properly:
>ara Arabic,
>my Malay(Jawi, Arabic Keyboard),
>iq Iraqi

These layouts cause the character "h" to not display properly:
>cz Czech,
>sk Slovak

These layouts cause the character "'" to not display properly:
>nl Dutch


These layouts cause the character "\" to not display properly:
>is Icelandic,
>lv Latvian,
>tr Turkish,
>sn Wolof

These layouts cause the character "[" to not display properly:
>jp Japanese

These layouts cause the character "." to not display properly:
>la Lao

These layouts cause the character "w" to not display properly:
>mn Mongolian

(In reply to Oussema Bouaneni from comment #5)
> I'm sorry if my meaning didn't get across well.
No offense taken, sorry if my matter of facts answer came of as rude.

Thanks for your good keyboard layout analysis, that confirms the suspicion it is the old bug that is resurfacing in at least in bug 310881, bug 401806, bug 402913 and bug 422329. The only thing you can do is spend your votes on these issues where you can and hope somebody will take on the bug (or at it gets confirmed).

(In reply to Henning from comment #7)
>sorry if my matter of facts answer came of as rude.
No offense taken :)


>The only thing you can do is spend your votes on 
>these issues where you can and hope somebody will
>take on the bug (or that it gets confirmed).
Thank you once again for your time. I voted for the only one of these bugs I could. Now we just wait.

I've seen this on other systems as well and debugged that together with dfaure quite a while back.

IIRC, the issue is that kglobalaccel looks at the key syms in the sequence, queries all key codes which can produce this sym with any modifiers and registers grabs for them. If one of those modifiers is one that Qt does not support (Mode_switch?) then it's grabbed anyway but interpreted wrongly, which results in lost events.

In the case of a grab for "`" breaking 4, check the output of "xmodmap -pke | grep grave", it probably includes a line with the keycode for 4.

*** Bug 424000 has been marked as a duplicate of this bug. ***

Possibly related to Bug 423305?