Superstition? Depends on how stringent your requirements are.
On IBM PC compatible hardware, there's always a risky "window of
opportunity" that a shared edge-triggered interrupt line gets
electrically re-triggered before your ISR manages to service all the
devices and ACK the interrupt (I believe RTAI does that in reverse
order). In that case, you get a missed interrupt, and your
peripherial device may wait for service indefinitely.
I don't recall if the i8259 AT-pic has some useable "retrigger while
in service" register, maybe the APIC does. (I do recall that the
8259's two-register IO footprint is rather convoluted.) I seriously
doubt that the presence of such a register would completely eliminate
the critical window of time.
On PC hardware or in general, sharing edge-triggered interrupts can
be perfectly allright under very specific conditions, if you know
exactly what you're doing, e.g. you know that the collision of
interrupt sources simply cannot occur (due to some characteristic
sequencing of interrupt-generating events in the specific peripherial
hardware), or you don't quite bother (in that case, why use an
interrupt at all?).
You can certainly try to re-check your string of devices before
finally ACKing, or set up supplemental timer-based periodic polling,
but those are all kludgey workarounds that converge towards not using
interrupts at all. I believe this is one of the reasons why e.g. ISA
multi-port serial boards with a shared interrupt have been dropped
from Linux 2.6 (vs. 2.4).
The fact that some ISA peripherials do respect the open-collector
convention, so that electrical sharing of the IRQ line is possible,
doesn't help the ISR do the job in time. Even at the electric level,
this rule is far from notorious. I've had the opportunity to write a
driver for a special-purpose ISA board, where two different
generations of the hardware treated the IRQ line very differently. If
you use OC+pullup combined with active-low pulses of ...
