Weird Multi Key (Compose file) Inconsistencies

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?