Bug 12846

May self-translation help me. This personal story has been going on for a couple of years.

I don't know how it is implemented in the code, but from the experience of using GNOME, I came to the conclusion that there are three separate mechanisms of keyboard operation. The difference is especially noticeable on the keyboard combination of switching layouts.
I don't remember exactly if there is a switch of layouts in Italian, but in Russian it is.

Therefore, I will lengthen the story a little with an example from Russian.
Since Windows, the most popular combination of changing the layout has been Ctrl+Shift. In second place more often it was Alt+Shift. According to the polls, it remained that way. Although later the CapsLock option was added as a "combination", which I was rather surprised at.
Windows later tried to impose a combination of Win + Space. It got into the polls, but the combination did not gain popularity.

This is most likely why we have two combination options in tty - Ctrl+Shift and Alt+Shift. Maybe there are some other combinations, but there are very few of them in tty.
There are many more options in X11. There was even a division, for example, into LCtrl + LShift and RCtrl + RShift and so on.
It's still more fun in wayland. There was a division into... LCtrl+LShift and LShift+LCtrl and so on. Yes, yes, these are different combinations. If, with relatively fast printing, we do not want to be surprised by a failed switch, then we need to prescribe both LCtrl +LShift and LShift+ LCtrl at the same time.
However, it seems that in wayland no one has added any connection between the combinations and the GUI of setting combinations.
Moreover, in GNOME wayland Rosa, I myself added the saving of the selected layouts themselves. At least the layouts are called the same. That is, ru is ru, en is en, fr is fr in both X11 and wayland. I just read the layouts exposed in X11, and with the command I set these layouts in wayland. Two lines turned out.
But with a keyboard shortcut, for obvious reasons, such a trick will not work.
Instead of compiling tables for processing combinations read from X11, I just put three combinations into the default system. That is, LCtrl+ LShift, LAlt+ LShift and Win+Space (people asked, poor young people already "processed" by the new Windows). More precisely, I set all five combinations: LCtrl+LShift, LShift+LCtrl, LAlt+LShift, LShift+LAlt and Win+Space. Space+Win does not exist, otherwise I would have put it up.

As far as I've heard, KDE has just switched to wayland.
I apologize for the politics in the text. If it gets in the way, just don't read on. I think the conclusion is obvious: keyboards are not fully encoded for wayland.
Next, it's just my thoughts on why it turned out badly, and what we should expect.

When GNOME switched to wayland a couple of years ago, the political situation in the main native English speaker had not yet reached the peak of the culture of canceling all Russian. I think the peak of this behavior has not been passed even now. However, this winter will make a big adjustment of behavior in Europe. Probably, next winter will do something similar in the United States, but due to the availability of resources, it will be on a smaller scale.
In my opinion, this will affect everything except Russia. Even if the West is no longer willing or able to engage in industry (and, as a result, this affects even the keyboard predictably and consistently), Russia has redirected the surplus "blood of industry" to China and India, in parallel, Russia has increased domestic consumption and industry.
It's still an illusion that open source software can develop on its own. It is necessary to get rid of the main production, and the stomach will become hungrier. Accordingly, free time will be sharply reduced for the development of open software. In my opinion, the prerequisites for problems with the keyboard are exactly this.
In Russian GNOME Rosa, I corrected the situation with keyboards (and translations) a year ago. There is no one to debug in the languages of Europe. More precisely, I tried it at the request of a user from Poland (https://bugzilla.rosalinux.ru/show_bug.cgi?id=11980 ) slightly improve the situation with the preservation of layouts, and rolled back the English names for non-Russian layouts. As far as I could. I wouldn't call myself a programmer.
By the way, in my Republic (Mordovia, Russia), in addition to the Russian language, there are two more state languages - Moksha and Erzya. There is Tatar, even if this language is not the state language. There are several Tatar settlements. I have also met the Ukrainian language. Probably, I have also met Belarusian, I just did not understand that this language is Belarusian. We have several stores open from Belarus. In fact, I would like to add all these languages, because I hear them in real life. But I do not know these languages myself and do not have the resources or sufficient communication skills to do this. 6 years ago, I didn't know about the existence of linux. The code was something strange to me.

(In reply to Grigorev Andrey from comment #1)
> May self-translation help me. This personal story has been going on for a
> couple of years.
> 
> I don't know how it is implemented in the code, but from the experience of
> using GNOME, I came to the conclusion that there are three separate
> mechanisms of keyboard operation. The difference is especially noticeable on
> the keyboard combination of switching layouts.
> I don't remember exactly if there is a switch of layouts in Italian, but in
> Russian it is.
Sorry Andrey, I fear I cannot follow your reasoning...

The issue I'm (and others are) seeing has nothing to do with keyboard layout switching: I usually install the OS in English and then add IT keyboard layout to match the hardware I actually have, so I can switch between en_us and it_it and this works without a glitch.

In my original Fresh 12.1 Plasma5 install all was working as expected, but after some plasma update I started to see the issue at hand(*), so I guess something changed in the way QT or KDE are managing the keymaps and this in turn partially broke the IT one...

(*) Unfortunately I cannot tell the precise date of this: I was aware of it after an unknown time period, when I tried to insert a "#" in a specfile I was updating and this printed the wrong symbol...

I can confirm that is a plasma-only issue...
In a VM I switched to a text terminal (Alt+F3) from the greeter screen, before logging in the plasma desktop and in that terminal the IT keyboard correctly prints "#" and "@".

Still an issue with next 2023.1...(In reply to Giovanni Mariani from comment #3)
> I can confirm that is a plasma-only issue...
> In a VM I switched to a text terminal (Alt+F3) from the greeter screen,
> before logging in the plasma desktop and in that terminal the IT keyboard
> correctly prints "#" and "@".

I would like to add that the "Preview" tab in the plasma System Settings for the keyboard (System Settings->Input Devices->Keyboard->Layout) shows clearly the wrong mapping:
- "@" is mapped as AltGr+Q and not as AltGr+ò.
- "#" is not present at all (and it should be AltGr+à).

The issue is also present in a fresh plasma install of the next 2023.1:
- when selecting in anaconda an Italian keyboard all works as expected
- after starting plasma I can see the issue in all its glory...