For those who don't know,
The Multi Key is a key you can set on linux, with which you can type an insane amount of unicode characters. It is commonly bound to scroll lock, I will represent it with ↓ here.
A few examples of shortcuts would be
↓TM → ™
↓|v → ↓ (the character I am using here)
↓+- → ±
↓co → ǒ
Now, most of those work just fine in Firefox, but weirdly there are some that don't. For example ↓PP produces ¶ just fine, but ↓RR doesn't type ℝ. for ↓RR the Multi Key input stops, like it does once no more valid sequences are left that match the current input. ↓CC also doesn't type ℂ, but it doesn't stop but continue on as if there was a different sequence starting with CC. I don't see anything special about the sequences that don't work compared to the majority that do.
After some trial an error, I think what is happening is that firefox does read my .XCompose, but the line include "%L", that is supposed to load the default Compose file located in /usr/share/X11/locale/en_US.UTF-8/Compose is ignored. It is not a language configuration error, as include "/usr/share/X11/locale/en_US.UTF-8/Compose" is ignored too. Entering some deliberate modifications or even removing existing sequences from the Compose file doesn't affect Firefox.
I even found some sequence ↓a_ which is supposed to yield ā but firefox has as ª (not to be confused with ᵃ the superscript a) instead.
Searching for the place Firefox' Compose is defined, I grepped for "ª" which is a pretty rare character, and hit libxul.so. I tried a bunch of other characters and found pretty much everything that has a compose sequence is found in that file.
So thus my question would be: Are Firefoxes default compose sequences statically compiled into libxul.so? And if so, why?
"Solution":
GTK has weird compose sequences baked in and refuses to read the correct locale default ones from the proper files, only reading the userdefined file. The only option is to override this by adding the default locale file to the userconfig. A sane way to do this while keeping .XCompose small is described below.
I am on wayland. The Compose system has nothing directly to do with X11, other than it happening to be from the same time period, as such the name .XCompose for personal modifications.
But seems your call on gtk was right, I checked what other software uses gtk and it seems gimp has exactly the same weird behavior.
The compose system is how "dead keys" are implemented I think, plenty of keyboard layouts don't have a key for each character but say ´ which you can type then type a to get á. The Compose file then contains
<dead_acute> <a> : "á". Without it, all those dead key combinations would stop working. the<Multi_key>is basically just an extra dead key for general unicode input, so you also have<Multi_key> <acute> <a> : "á"i.e. ↓´a → á in case your keyboard doesn't have the<dead_acute>