Read the CPUINT chapter in the datasheet.
There is now 2 interrupt priorities on these newer avr0/1/2/dx devices (only 1 irq can be the higher priority). To make that work, they cannot automatically hardware disable the global irq enable when entering an isr as it would render the higher priority irq level useless. Instead you will find in the CPUINT peripheral a STATUS register that 'keeps track' of which interrupt level you are in, and when a reti instruction is executed the level will decrement (or simply the lvlex bit clears for the current level).
irq_a fires (level0),hardware sets cpuint.status.lvl0ex bit, jumps to vector table for irq_a
irq_a isr runs (global irq bit still set), any level0 irq cannot interrupt this isr
irq_c fires (level1), hardware sets cpuint.status.lvl1ex bit, jumps to vector table for irq_c
irq_c runs (global irq bit still set), nothing can interrupt this isr
irq_c isr does a reti, lvl1ex bit clears, returns back to irq_a (lvl0ex still set)
irq_a does a reti, lvl0ex bit clears, returns back to main code
One problem that does show up because of this- if you let the default bad interrupt handler do its normal thing (I think it still does this), which is to simply jump to 0 (bad idea in any case), the lvlex bit remains set because no reti has been seen and you end up in your app again with irq's effectively disabled. A better thing to do is to create your own __vector_default function (then called by __bad_interrupt) to handle any inadvertent irq and simply do a software reset (and whatever else you want to do).
Not something normally done, but you also cannot re-enable your current level irq state inside an irq unless a reti is executed. One way to do this would be to call an asm 'function' that simply does a reti.