In my case, the actual speed wasn't as important as consistency.  The project was a contest entry for the Atmel / Circuit Cellar 2004 AVR contest.  The project (here http://wrcooke.net/projects/vidovly/avrcog.html) was a device that synced with and overlaid text on a standard NTSC video signal.  An incoming horizontal sync pulse caused the interrupt, which then pulsed a row of pixels of the text on top of the video.  Although the response needed to be fast (less than a few microseconds) it was much more important that it happen at "exactly" the same time after each interrupt.  Otherwise the rows of pixels would jitter unacceptably. Since there was no way to ensure equal interrupt response while running code, I used a method similar to the one you related: I halted the CPU when I was awaiting the incoming interrupt.  I don't remember where I got the idea, but I didn't originate it.

It worked pretty well, but there was still some jitter.  I attribute that to running the CPU at 10 MHz rather than an even multiple of the horizontal sync rate.  I was able to receive characters from the serial port and display 120 (6 rows of 20 characters) overlaid on a video signal using an AT90S2313 with 128 bytes of RAM.  I don't think that code would have been possible with anything other than carefully tuned assembly language.

I once built a 230V dimmer that featured output short-circuit protection. I used a basic current shunt resistor and a window comparator to detect overcurrent condition. The crux was that it had to react fast - before the current killed the output MOSFETs. I initially wrote the interrupt handler in assembly; on a 24MHz 8051 derivative the worst-case latency was about 20 cycles, or 0.84us, to disable the MOSFET driver. It worked well - except one condition: the interrupt would be masked if an internal flash write operation was in progress - and we did use the internal flash as non-volatile memory. The result was, well... a bit explosive. I ended up using a hardware solution to quickly crowbar the MOSFET gates to ground as soon as the window comparator triggered - without waiting for the MCU to notice. I also learned to cover the prototype with a tupperware box so the flying bits of TO-220 cases wouldn't shred my face.

I think that some advances with peripherals and devices have changed a lot the interrupt response time requirements. First came peripherals as DMAs to help it, then for any recent device you'd employ some smart magic in an FPGA, to automate even more complex tasks -- for a system I had, which was sampling 8 channels of analog data at 12-bits every 2 microseconds, I simply resorted to an FPGA buffering trick as well.

I often have had sampling of data every 20-30 microseconds, even on 8-bit CPUs in the 80s and 90s, but that was still manageable, even in C language.

Funny enough, the most stringent interrupt request that I remember, along with a funny trick, wasn't that "fast".

Crossing the end of 80s and beginning of 90s we used in an industrial site some Z80 controllers from Rabbit Semiconductor. Their Dynamic C language/programming environment was cool enough for us, then I instructed a colleague on using that, except for the critical parts that I managed myself.

We had an industrial rotational encoder connected, with the classic A-B phases, which had to be first monitored not for speed, but for bi-directional step count.

The Z80 CPU on those systems was connected to a Z80 PIO, summing that up with the "moderate optimization level" of Dynamic C, it ended to be highly critical at our "high speeds".

I proposed an implementation that my boss accepted with a half-hearted "if you're confident that it works..."

The system did run with two interrupts on A and B phase, to capture the two directions, and it was impossible for the system to run at maximal speed and being inverted in direction in zero time.

Then I developed a "variable interrupt" handler, which at higher speeds started counting steps only from one phase, ignoring the other until it slowed down again. And it worked very well!

Philips 87C751 had a PWM with NO buffer. Which meant the only way to change the comparison value was before the comparison triggered, or unpredictable results ensued. I solved this by putting a one instruction load at the interrupt vector, followed by a RETI. The total time was less that the minimum usable value in our system, so no problem. Yes, I did check the value for min and max before putting it into the static fetch location for the interrupt.

I once worked on a 68HC16 processor running a foreground loop with relatively non-critical timing and an ISR that generated five channels of tones using sine-table lookups.  If a channel was turned off, it would branch past its tone generation code so it didn't use much processor time.  That worked great when only one or two channels were active, but it couldn't keep up when all five were active, even after we applied every assembly language coding trick we could think of.  The eventual solution was to eliminate all of the branches and turn off the unneeded tone generators by setting their sine table pointer increments to zero so they generated the same value each time.  That made the ISR use the same number of processor cycles no matter how many channels were active.  It was hard to directly measure what percentage of the processor's time that ISR used because just setting an I/O line high at the beginning of the ISR and clearing it at the end pushed it over the edge.  But we could measure the percentage slowdown of the foreground control loop and found that the small number of remaining processor cycles were enough to keep it running acceptably fast.

I can't claim any special experience of designing super-fast interrupt hacks - bit I'd like to present, if I may - an alternative take on that.

I have to admit that in general I try to avoid having to do unusual hacks to get components to do what I need them to. If I would need to respond to an event in a fraction of a microsecond, I might prefer to design some hardware to capture the most time-critical parts of the event, and allow a processor to respond in a more conventional fashion - if that were possible, of course.

I feel that as engineers, we are all too easily seduced by the "heroic" model, if I may call it that. I find that there is sometimes a good moment to stand back and ask whether I chose the right tool for the job. I very recently encountered this myself - having struggled to get some I2C hardware working reliably as part of a more complex system - and someone (the person paying for the job) pointed out that I could as easily use a straightforward serial link. He was right, and I'm embarrassed that I didn't think of it. It cost about a week of my time. (Luckily for me he's an understanding guy.)

(Of course I realise that "back in the day" unconventional approaches could achieve things which are more commonplace now. It's just another point of view, as I say.)

You say: "I believe MISRA is incomplete as it doesn't address stylistic issues. These include the placement of braces, indentation, and the like. Every organization has their own take on these; sometimes they constitute the catechism of a religious war between developers. Fight a war over design issues, not style. Clarity is our goal; when inconsistent styles are used one's eyes get tripped up by odd structures."

I have seen the same thing.  My way of solving this problem is to use the "hooks" that most source control systems support, to run a python script that reformats every checkin and checkout to the current company standards.  Then the religious wars can be fought over what goes into this script--with one person making the final decision based on the best arguments--but whatever goes into or comes out of source control contains consistent formatting.  Once a developer doesn't have to do any work to format code the accepted way, I find there are a lot fewer wars.  Code as you like, with the knowledge that what everyone else will see will be formatted in the accepted manner, as will the code, written by others, that you checkout.

I had an interesting issue today debugging a system which was going AWOL despite a reasonably well designed watchdog.

It seems the watchdog was checking everything inside the processor was going okay. But wasn't testing those special function registers which are set at startup and then forgotten - such as TRIS registers.

It turned out that the TRIS registers for a bunch of signals driving relay outputs would occasionally assert themselves to the input direction. But the watchdog just carried on as normal and the output latch registers were being asserted okay.

Just adding a few lined of code to test the TRIS registers before clearing the watchdog made a whole bunch of problems go away. The lesson is to consider the scope of what you want the watchdog to supervise.