I am still poking around this area too.

This points to the "edge" meaning the type of irq is an "edge falling" irq: https://www.raspberrypi.org/forums/viewtopic.php?t=20931

Looking at mine, I have "18 edge" and that ties in with the GPIO-18 I expect the interrupt to come in on in my case :

       CPU0      CPU1   CPU2  CPU3
172:   1387      0      0     0     pinctrl-bcm2835  18 Edge      lirc_rpi

To the best of my knowledge, when you write software dealing with the interrupts, the IRQ number you will handle always comes from the first column. That's what the CPU is seeing.

The 4th column reveals some details about the interrupt controller, and as you have seen, its format is very platform-dependent. A complex SoC may have more interrupt sources than the CPU supports (for instance, most pins can generate interrupts), so the job of the interrupt controller is to establish a mapping between such sources that are actually in use and the IRQs.

Personally, I would not try to parse the 4th column at all and trust the 5th column instead. E.g. if the interrupt channel 89/Edge is called uart-pl011, I would expect it to be an UART interrupt. So, I needed to deal with UART, I would have to service IRQ 81, listed in the first column on the same line.

As you can see in the source of the kernel, it displays all possible irqs of the system.
In source/fs/proc/interrupts.c:39 a sequence operation is initialized to return as many elements as interrupts exist in the system for /proc/interrupts.

In source/kernel/irq/proc.c:479 we can see that the counters of every interrupt gets extracted from global counters via kstat_irqs_cpu(irq, cpu).
This means the interrupt count information gets updated in different counters, one for each cpu. The counters get summed upon reading the proc file. This is a common pattern in the kernel. It prevents contention on a global counter.

More onfo about per-cpu variables you can read here. More about interrupts in linux you can get here.

watch -n0.1 --no-title cat /proc/interrupts

You are correct: they relate to the IO-APIC system. ERR is documented in the kernel documentation in Documentation/filesystems/proc (lines 677-680):

ERR is incremented in the case of errors in the IO-APIC bus (the bus that connects the CPUs in a SMP system. This means that an error has been detected, the IO-APIC automatically retry the transmission, so it should not be a big problem, but you should read the SMP-FAQ.

AFAICT you shouldn't see this unless there is a hardware issue. As the documentation indicates, it's something that you show note and investigate if it happens frequently.

MIS doesn't show up in the documentation, but this Gentoo forum message from 2005 talks about it. The current arch/x86/apic/io_apic.c (lines 1797-1806) has the following comment:

It appears there is an erratum which affects at least version 0x11 of I/O APIC (that's the 82093AA and cores integrated into various chipsets). Under certain conditions a level-triggered interrupt is erroneously delivered as edge-triggered one but the respective IRR bit gets set nevertheless. As a result the I/O unit expects an EOI message but it will never arrive and further interrupts are blocked from the source. The exact reason is so far unknown, but the phenomenon was observed when two consecutive interrupt requests from a given source get delivered to the same CPU and the source is temporarily disabled in between.

As this comment (and code) haven't significantly changed in over 10 years (other than kernel restructuring), I'm not sure how relevant it is today, but it is very small and protects against a strange hardware quirk.

The files that I looked at were from version 4.15.10 of the kernel. Your sources may vary.

Remote function call interrupts belong to the family of Inter-Processor Interrupts, that is interrupt signals sent by one processor to any other processor in the system and delivered not through an IRQ line, but directly as a message on the bus that connects the local APIC of all CPUs.

Remote function call interrupts are generally sent to all processors but the sender, forcing those to run a function passed by the sender. Under a linux x86 kernel :

The corresponding interrupt handler is named call_function_interrupt( ).
The interrupt is usually sent by means of the smp_call_function( ) facility function.

Typical use cases include stopping all cpus when shutting down, calibrating clocks, flushing TLBs… and more.

Of course different smp-affinity settings can indirectly impact on the number of TLBs flushes but because this impact is indirect and because TLB's flushes are not the only reason for function call interrupts, their rate should not be used at first and alone to judge the efficiency or the affinity settings.

First judge of pertinence for smp-affinity settings is the number of context switches. The lower, the better.