Are you setting those options with the setxkbmap tool? If so, that is not supported, and please set those options through your compositor (e.g. GNOME Tweak Tool or weston.ini).

No, i am setting these options using the method, recommended by the WM (weston.ini for Weston; XKB_* variables for Orbment). The setxkbmap tool was used in an attempt to narrow the problem down to the component responsible.

I'm probably affected by this too. I am not using setxkbmap, but gnome-control-center.

$ localectl
   System Locale: LANG=de_DE.UTF-8
       VC Keymap: de-neo
      X11 Layout: de,de
     X11 Variant: neo,nodeadkeys
     X11 Options: grp:sclk_toggle

I also have been affected by something similar to this I think.

Though, what I've experienced is that the layout is switched back us-dvorak-alt-intl from svdvorak after entering one character. For example what I have seen has been:

1. Switch to svdvorak
 * switched to svdvorak *
2. Press å
 * å is entered *
 * silently switched to us-dvorak-alt-intl in xwayland *
3. Switch to svdvorak
 * switched to svdvorak *
4. Press ¨ (dead key)
5. Press o
 * ö is entered *
 * silently switched to us-dvorak-alt-intl in xwayland * (or after 4., I don't know, o is in the same place)

Settings and switching has been done using GNOME. I don't know how to reproduce this reliably, and it doesn't happen that often. IIRC sometimes I haven't even been able to switch to svdvorak for entering one letter.

$ localectl
   System Locale: LANG=en_US.UTF-8
                  LC_NUMERIC=en_DK.utf8
                  LC_TIME=en_DK.utf8
                  LC_MONETARY=en_DK.utf8
                  LC_PAPER=en_DK.utf8
                  LC_MEASUREMENT=en_DK.utf8
       VC Keymap: us-dvorak-alt-intl
      X11 Layout: us,se
     X11 Variant: dvorak-alt-intl,svdvorak

So I found out what caused the issues on my end, but I cannot verify it is what is causing issues for others.

So in my case, as described in comment 4, the layout switch was only valid for one key. After some digging, the reason was a bag X11 client; in my case a nested mutter instance (i.e. running mutter as a nested Wayland compositor on top of X11) trying to have a say in the XkbState. Mutter normally does this, being the window manager, but when running nested, it's not a good idea to mess with the host X11 servers xkb state.

So, if anyone still is hitting this, this is a way to find out what client is screwing up the state (assuming its the same type of issue).

 1. Set the keyboard layout you want and focus an X11 client
 2. From another computer, attach gdb to the Xwayland process
 3. Add a break point on the 'event_get_corestate' function
 4. Press some key to trigger some X11 key event
 5. When the breakpoint hits, add a hardware watch point on the value the '&kbd->key->xkbInfo->state.locked_group' pointer points at (e.g. "watch *(unsigned char *)0x123456" where the above pointer is 0x123456.)
 6. Disable the breakpoint on 'event_get_corestate'.
 7. Continue gdb
 8. Reproduce the issue
 9. Check that gdb have stopped, hopefully in ProcXkbLatchLockState()
10. Inspect the client mask: printf "0x%x\n", client->clientAsMask
11. Look up what client it is by comparing the mask with the windows listed by xwininfo -root -tree. For example if the client mask above was 0x1600000, try "xwininfo -root -tree | grep 0x16".

Note, there might be a better way to intercept and examine client protocol traffic that I don't know about. The key point is to find what client tries to mess with the xkb state.