Through the GNOME Tweak tool, I set a Compose key in place of CapsLock. Looking in dconf, it seems a key was properly set up, so I am assuming the issue is not within GNOME Tweak tool: org.gnome.desktop.input-sources xkb-options ['compose:caps']

The problem is that the CapsLock indeed now works as Compose key but it still also works as Caps Lock!

Steps:

• Be in "English (US)".
• Set 'compose:caps' in org.gnome.desktop.input-sources xkb-options (or just use GNOME Tweaks Tool, in the "Keyboard & Mouse" tab, there is a "Compose Key" option which does the work for you).
• Hold CapsLock + o + e.

Expected result: the light on the CapsLock key must not switch on, Capitalization of letter must not be locked for subsequent letters, and "œ" must be outputted.

Actual result: the light on the CapsLock key goes on, Capitalization of letter is locked for subsequent letters, and "Œ" is outputted.

So "compose:caps" did not just override the CapsLock behavior but instead added the compose behavior (and the key does both at once, which is weird).

This could also be a bug in XKB, but if you run the following as command line:

setxkbmap -layout us -option compose:caps

Then CapsLock works only as Compose key, as expected. This tends to imply that maybe GNOME does not properly set the option. Also note that this used to work fine until Fedora 25, and stopped in Fedora 26 and higher (in case it helps with version numbers of packages in the input stack).

Finally if GNOME shell is not the component handling input sources in GNOME, I hope you can just re-assign this bug report (do we have the feature in gitlab?). Thanks!

Note: the issue does not happen as an exception with some layouts which override the CapsLock, for instance the Japanese layout. Yet it happens for most layouts. This is why my reproduction steps above use "English (US)" but the same issue happens anyway with most other layouts.