Windows 11 language switch hot keys don't always work or work slowly.

I have an (2?) update for this:

(1) There is an opensource tool called 'Keyman' (on website of same name), which fixes this. It is a 'bigger brother' of the windows built-in keyboard-layout manager, but as a side-effect, it is also much better and more efficienty/correctly implemented! Since I installed this, I can now switch keyboards like I _used_ to be able to do in windows, for the last 40 years.

(2) I also believe to have found the culprit for the new win-11 behaviour: It appears they are using their own UWP/WinUI framework for new windows features, and this is exactly the level of (lack of) performance that I encounter with UWP applications. TLDR - to fix it properly, they would have to stop developing their own modern UI features with the equivalent of electron :-/.

There is a third alternative if you want.. As of may 2025, it only takes about 40 lines of code, to implement keyboard layout switching in e.g. C#
So we could program our own, and just avoid using UWP..
  I include a sample I made here - beware it doesn't have any UI component, so it would just set all top level windows to use a given layout:

using System;
using System.Text;
using System.Runtime.InteropServices;

using HKL = System.IntPtr; //System.Runtime
class Program {
    private delegate bool EnumWindowsProc(IntPtr hWnd, IntPtr lParam); // Delegate matching EnumWindows signature


    [DllImport("user32.dll")]                      private static extern bool EnumWindows(EnumWindowsProc lpEnumFunc, IntPtr lParam); // Import EnumWindows from user32.dll   
    [DllImport("user32.dll", SetLastError = true)] private static extern int GetWindowText(IntPtr hWnd, StringBuilder lpString, int nMaxCount); // Import GetWindowText and GetWindowTextLength to retrieve window titles
    [DllImport("user32.dll", SetLastError = true)] private static extern int GetWindowTextLength(IntPtr hWnd);
    [DllImport("user32.dll")]                      private static extern bool IsWindowVisible(IntPtr hWnd); // Import IsWindowVisible to filter visible windows


    [DllImport("user32.dll", SetLastError = true)] public static extern bool PostMessage(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);
    [DllImport("user32.dll")]                      public static extern IntPtr LoadKeyboardLayout(string pwszKLID, uint Flags);


    static void Main() {
        Console.WriteLine("Enumerating top-level windows:\n");


        EnumWindows((IntPtr hWnd, IntPtr lParam) => {
            if (IsWindowVisible(hWnd)) {
                int length = GetWindowTextLength(hWnd);
                if (length > 0) {
                    StringBuilder sb = new StringBuilder(length + 1);
                    GetWindowText(hWnd, sb, sb.Capacity);
                    Console.WriteLine($"HWND: {hWnd}, Title: {sb}");
                    tryToChange(hWnd);
                }
            }
            return true; // continue enumeration
        }, IntPtr.Zero);
    }

    public const int WM_INPUTLANGCHANGEREQUEST = 0x0050; // #define WM_INPUTLANGCHANGEREQUEST 0x0050
    public const int KLF_ACTIVATE = 0x00000001; //const uint KLF_ACTIVATE = 0x00000001;
    static void tryToChange(IntPtr hWnd) {
        HKL hkl = LoadKeyboardLayout("00000409", KLF_ACTIVATE); // "00000409" = English (US)
        PostMessage(hWnd, WM_INPUTLANGCHANGEREQUEST, 0, hkl); // IntPtr (LPARAM)
    }
}

2025-late-april, this bug still here, same as OP described better than I can.
All of my win11 machines exhibit this bug. My remaining win10 machines - as with all prior win-OS - do not exhibit this bug.
Basically, keyboard-switching has been broken to be unusable for people who actually need/rely on it (hint: everybody outside US).
There may be several bugs.
(1) on my machines, the UI for this appears to "animate", the same way slow web apps are wont to do.
Which makes no sense, for a user interface interaction which must be INSTANT. I am trying to 10+ characters per second. I do not need a multi-second "movie" event while I am typing??
(2) it feels like the bug has some sort of "getFocus/leaveFocus" issue, where the keyboard-switching maybe is tied to some sort of "select confirmation", so it is not enough to navigate down to the intended keyboard-option in the select list, the selection must sort-of-be 'confirmed'? possibly by some sort of focus-ended-event? I am not sure, but it feels like it, as I can see the intended language being HIGHLIGHTED/SELECTED, but my key presses continue to type the previous other keyboard layout, suggesting that the displayed/highlighted item is not 'confirmed'..?
(3) another way to describe my suspicion: It appears as though the actual switch EFFECT is not tied to the typed-"SWITCH-NOW" key command, but instead somehow tied to that the (secondary) UI part is "updated to reflect it". Which is insane - switching of keyboard layout should be INSTANT.

I wonder if the guys at microsoft (*) understand the usecase here:
It's not like people in europe wake up on a wednesday and think "You know, today, I think I will switch to ITALIAN keyboard layout, maybe around noon..?" 
  We don't switch keyboard layout once per day, we switch multiple times per minute, as we e.g. switch back and forth between US layout for coding, and european layouts for any text we need to write.

(*) The product managers, the product owners, whatever else MS throws at this.

So far, what I can see is that across a YEAR - 12 months - nobody at 'the biggest software company in the world' has cared to address this?

Hello? Anyone at microsoft still using keyboards? Can you look into this at some point? Maybe allow me to code it for you?
At this point, I'm considering coding my own "switch keyboard layout" app for windows, there has been a market for such an app for 12 months now..?

hey idk what it is but it has something to do with sticky keys just search sticky keys on search bar and turn everything on at least it worked for me