My first guess was that the IO APIC (or PIC?) wasn't configured correctly (e.g. SCI configured as "level-triggered active-high" when it's supposed to be something else); but I looked into that yesterday and found that "level-triggered active-high" is correct (according to Intel's ICH7 datasheet).
Level-triggered active-high is indeed a strange configuration because the XT PIC does not support this configuration at all. However I guess the ICH does a traditional PIC in hardware anyways and just emulates the register interface to software so that does not matter.
My second guess would be some form of race condition. For example; installing the SCI handler and enabling the IRQ in the PIC or IO APIC before the chipset/motherboard has disabled its SMI (before or after "ACPI_ENABLE" is sent to "SMI_CMD"); causing whatever triggered the event to be handled by firmware's SMM code before the operating system's SCI handler is started.
It turns out that this was indeed the case. The SCI had nothing to do with ACPI_ENABLE; it also happens if I do not switch to ACPI mode at all. The sequence of events was
Disable interrupts => Unmask I/O APIC => Some time passes => IRQ 9 level is asserted (probably by the PM timer or some SMI/TCO/whatever stuff?) => Enable ACPI => Enable Interrupts => IRQ 9 is delivered to the CPU
when I move the unmask after
ACPI_ENABLE no IRQ is raised (i.e. the IRQ is swallowed by the masked APIC).
The behavior is strange because I don't remember ever getting random IRQs when I used the XT PIC. However my current kernel only supports the I/O APIC so I cannot verify that. I guess I'll have to implement XT PIC support in order to further investigate that issue.
Thanks for your comments!