I can confirm this bug. 
Numpad numbers (KP1-KP9) are seen same as just number on keyboard (1-9), which are mapped to totally different functions.
It's also just ignoring some keys like `KP_Divide` (/) or `KP_Subtract` Numpad (-) when assigning them in combination with Ctrl+Alt
It's not possible to use them as a shortcut (i.e. Ctrl+Alt+KP_Divide is not working)

also confirming this issue on KDE Neon, Plasma 5.25.2, kde frameworks 5.95.0
with X11 session everything works, on Wayland it's impossible to use numpad as separate keys in any keyboard layout (tried US, CZ and RU)
it's not "one layout issue" as I have more layouts configured in system

Same on Fedora 37.

In X11 session I have Meta+4 == switch to 4th desktop and Meta+Num4 to be "move window to left side of screen". I am getting tired of seeing 4th desktop again ;D

kde frameworks 5.99 and 5.26.2, problem still exists

Cannot reproduce on Arch Linux. I can set ctrl+1 and ctrl+2, for example, and they work.
I use brazilian portuguese (abnt2) keyboard layout.

(In reply to Patrick Silva from comment #5)
> Cannot reproduce on Arch Linux. I can set ctrl+1 and ctrl+2, for example,
> and they work.
> I use brazilian portuguese (abnt2) keyboard layout.

It's not about ctrl+1 or ctrl+2, but about different mapping of ctrl+1 on numbers above leteters and ctrl+1 when "1" is pressed on additional numeric keyboard. On X11 it works (it's different) but on Wayland that "1" is the same on basic and additional part of keyboard :(

Can confirm this bug on Arch Linux, too.

KDE Plasma can not tell the difference between number pad keys and their normal variants. This includes the numbers when NumLock is on but also PgUp, PgDown, Home, End etc. available when NumLock is off..

wev says:

[14:     wl_keyboard] key: serial: 2056; time: 820672; key: 10; state: 1 (pressed)
                      sym: 1            (49), utf8: '1'
[14:     wl_keyboard] key: serial: 2057; time: 820784; key: 10; state: 0 (released)
                      sym: 1            (49), utf8: ''
[14:     wl_keyboard] key: serial: 2058; time: 822544; key: 87; state: 1 (pressed)
                      sym: KP_1         (65457), utf8: '1'
[14:     wl_keyboard] key: serial: 2059; time: 822632; key: 87; state: 0 (released)
                      sym: KP_1         (65457), utf8: ''

So for Wayland those are two separate keys as they should be. Why KDE thinks otherwise?

And when bug gets closed as WONTFIX?

Updated to Fedora 38 and checked. Bug still applies.

KDE Framework: 5.104.0
KDE Plasma: 5.27.4
Qt: 5.15.9

(In reply to Marcin Juszkiewicz from comment #8)
> wev says:
> 
> [14:     wl_keyboard] key: serial: 2056; time: 820672; key: 10; state: 1
> (pressed)
>                       sym: 1            (49), utf8: '1'
> [14:     wl_keyboard] key: serial: 2057; time: 820784; key: 10; state: 0
> (released)
>                       sym: 1            (49), utf8: ''
> [14:     wl_keyboard] key: serial: 2058; time: 822544; key: 87; state: 1
> (pressed)
>                       sym: KP_1         (65457), utf8: '1'
> [14:     wl_keyboard] key: serial: 2059; time: 822632; key: 87; state: 0
> (released)
>                       sym: KP_1         (65457), utf8: ''
> 
> So for Wayland those are two separate keys as they should be. Why KDE thinks
> otherwise?
> 
> And when bug gets closed as WONTFIX?

I've got the same result. xev and wev reports different keys for '1' and 'KP_1' and the other keypad keys. On KDE x11 I can bind different shortcuts for '1' and 'KP_1' no problem, but under KDE wayland when I press 'KP_1' it acts as if I pressed '1'.

This bug prevents me from using kde wayland since I have several shortcuts mapped to all the keypad keys which really speed up my workflow.

I can'þ compile plasma with KF6 due to work, but would be nice to confirm if this bug still happens considering the migration to QT6.

Reproducible on gentoo with:
KDE Framework: 5.106.0
KDE Plasma: 5.27.5
Qt: 5.15.9

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

I can offer 50€ as kind of bug bounty. Should cover cost of pc105 keyboard as it looks that KDE developers only use laptops or small keyboards without numpad part.

Can confirm this bug also happens on Kubuntu 23.04 KDE Plasma Version 5.27.8

This bug is still present in:

KDE Framework: 5.104.0
KDE Plasma: 5.27.4
Qt: 5.15.9

Confirming this bug is still present on OpenSUSE Tumbleweed 20231031
NumLock is turned ON.

Operating System: openSUSE Tumbleweed 20231031
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.111.0
Qt Version: 5.15.11
Kernel Version: 6.5.9-1-default (64-bit)
Graphics Platform: Wayland

Keyboard: Corsair Strife RGB (104-key standard ANSI layout)
KDE Keyboard model: Generic | Generic 104-key PC

Keyboard Layout: English (US); English (US, intl., with dead keys)
(Neither fix this issue)

This does not happen on X11.

Within KDE shortcuts under system settings, pre-existing shortcuts involving the number pad appear like the following examples:
"Ctrl+Num+5"
"Alt+Num+5"
"Meta+Num+0"

I wonder if "Num" is being considered as a separate, non-existent key?
To test this, I tried using the NumLock key in a shortcut assignment. It actually reads as "numlock" and terminates the sequence.
I'm unable to get "Num" as a registered sequence step.

Possible duplicate of :

https://bugs.kde.org/show_bug.cgi?id=413310
https://bugs.kde.org/show_bug.cgi?id=446389
https://bugs.kde.org/show_bug.cgi?id=461291

These all describe the same problem.

According to the latest comment on 413310 this appears to be a bug in QT specifically.

That bug here claims to be "RESOLVED UPSTREAM", but I do not believe this to be the case.

The QT bug pages are both not listed as resolved at the time of this posting.

https://bugreports.qt.io/browse/QTBUG-57661

https://bugreports.qt.io/browse/QTBUG-94892

Also the keybinds work like normal on X11.

(In reply to Kyle B. from comment #17)

None of them are duplicates. At least bug #446389 is not!

First, considering the original report of this bug (as in: Numpad keyboard shortcuts can not be assigned in Wayland) this report should be closed as FIXED, as the keyboard shortcuts can be assigned, indeed. 

HOWEVER, many (me included) have commented on this bug report previously that KDE Plasma can not *differentiate* between normal keys (i.e. non-numpad keys, including PgUp, Home, End, cursor and the top number row above tenkeyless-part of a keyboard) and Numpad keys when running Plasma, when making shortcuts; meanwhile, running KDE Plasma under X.Org, it can can. Also, the OP mentions the keyword "exclusive" later on, which kind of hints he may have seen this misrecognition problem, too?

I'm certain I've meant to comment in Bug #446389 previously, but commented here instead - possibly because of having too many tabs open and mixing which tab I had open ;-).

#461291 seems to talk about Dolphin. #413310 seems to be a user wanting the OPPOSITE behavior than many other users. The duplicate keys found on the keyboard are recognized by the OS and are different on all keyboards, and alternative keyboard shortcuts exists for a reason (so, I would categorize that bug report as PEBCAK, as fixing it would break other users setups).

I suggest closing this as FIXED as it indeed "works" as Antti pointed out (but not as many expect as per bug #446389).

@Ville Aakko: to be honest I do not care which bugs will be closed and which left open as long as KDE/Wayland will recognize Meta+KP_4 and allow to use it as a shortcut.

https://bugreports.qt.io/browse/QTBUG-94892 is another one about the same.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5032

(In reply to Bug Janitor Service from comment #21)
> A possibly relevant merge request was started @
> https://invent.kde.org/plasma/kwin/-/merge_requests/5032

This fixes the global shortcut functionality in kwin.

https://codereview.qt-project.org/c/qt/qtwayland/+/533675 is needed for recording the key sequence in the KCM to work

Git commit 296d3f31be9f7148c4296a284d9c76271c6ed5bd by Vlad Zahorodnii, on behalf of Nicolas Fella.
Committed on 24/01/2024 at 14:20.
Pushed by vladz into branch 'master'.

Consider Qt::KeypadModifier relevant for global shortcuts

Otherwise kglobalaccel can't distinguish between numbers on the num block and other numbers
Related: bug 446389

M  +3    -0    src/xkb.cpp

https://invent.kde.org/plasma/kwin/-/commit/296d3f31be9f7148c4296a284d9c76271c6ed5bd

Git commit ae23df1f53e27229cb9d385a9dadfc8e2bc9ef08 by Vlad Zahorodnii, on behalf of Nicolas Fella.
Committed on 24/01/2024 at 14:26.
Pushed by vladz into branch 'Plasma/6.0'.

Consider Qt::KeypadModifier relevant for global shortcuts

Otherwise kglobalaccel can't distinguish between numbers on the num block and other numbers
Related: bug 446389
(cherry picked from commit 296d3f31be9f7148c4296a284d9c76271c6ed5bd)

M  +3    -0    src/xkb.cpp

https://invent.kde.org/plasma/kwin/-/commit/ae23df1f53e27229cb9d385a9dadfc8e2bc9ef08