Atmel has reproduced the behavior, and has escalated the issue. I asked whether it might just be a documentation error (reply #12 above).
Good catch there Jack. 
So that's Jack, myself, and Atmel.
Well at least we aren't going mad.
I know! That's what I always think in these situations! 
The final word from Atmel:
From: avr@atmel.com
Date: Fri, Oct 11, 2013 at 1:04 AM
Subject: (ATTicket:751590) External interrupt to wake ATmega328P from power-down
To: jack.christensenDear Jack,
You are correct, both edge and level based interrupt are waking up the device and the issue have verified with the internal resource. As you mention this has to be updated in the document and this will be updated in the upcoming release.
Thanks for your valuable inputs.
Sorry for the delay in response and Kevin is on leave so the ticket has assinged to meBest Regards,
Vincent Christopher
Atmel Technical Support Team
It's strangely vague about whether this is by design, or just happens on the chips that are tested.
It would be nice if they had said it is designed to do it.
I thought the same thing which is why I asked one final question, that was not answered (below). Assuming they were diligent about the whole thing, and also assuming that the update to the datasheet will make it read like the other ATmega datasheets, then I can only conclude that the observed behavior is by design.
From: Jack Christensen
Date: Fri, Oct 11, 2013 at 7:54 AM
Subject: Re: (ATTicket:751590) External interrupt to wake ATmega328P from power-down
To: avr@atmel.comHello Vincent,
No problem, thanks for the update. Just to be clear, the device is operating as designed, and the issue was with the documentation, correct?
Best regards,
Jack Christensen
Ticket Status: Confirmed Bug Feature
SirNickity:
Ticket Status: ConfirmedBugFeature
I really do think the chip is working as designed, and it was just a documentation error.
What was that old saying? Something like "A bug is a problem with the code, an error is a problem with the documentation." ??
I have been searching this forum / other forums for an explanation to my findings on m328p, and finally I see this thread. Thanx Jack!
I can confirm wake-up of m328p from power-down on rising/falling edge on INT0 pin. I used a minimalist setup running with 8Mhz internal oscillator on a breadboard, and the triggering edge was generated by a master m328p. After the wake-up, the slave m328p sent a digital signal back to the master that measured the start-up delay to be max 90 microseconds (BOD was disabled on power-down, and according to atmel's documentation this creates a start-up delay of 60us)
I also measured the supply current to the slave m328. In active mode current was 6-7mA, and on entering sleep the current drop to 0.2uA, which confirms that m328p entered power-down mode.
Have you got a link to your report, Jack? I submitted my own one yesterday and got this response (the implication being it was news to them) :
Commented by Manoraj Gnanadhas (Atmel)
2015-01-08 11:27:32 GMT
[Recipients: Nick Gammon]Hello Nick,
Thank you for contacting Atmel Technical Support.
It looks like a mistake in the datasheet. We tested here and also able to reproduce the same behavior here. If you refer “Section - 13. External Interrupts (Page-70)”, you can read the following information.
“Low level interrupts and the edge interrupt on INT2:0 are detected asynchronously. This implies that these interrupts can be used for waking the part also from sleep modes other than Idle mode.”
This is contradicting with the ‘Note-3’ mentioned under Table 10-1. Therefore I need to confirm this with the concerned team. I will get back to you once I receive any valid update from the design team.
Best Regards,
Manoraj Gnanadhas
I got this confirmation today that the datasheet was wrong:
Commented by Manoraj Gnanadhas (Atmel)
2015-01-20 06:23:36 GMT
(Recipients: Nick Gammon)Hello Nick,
Our design team has confirmed that “Note-3 mentioned under Table 10-1” is a datasheet bug. So you can use any type of interrupt (Rising edge/ Falling edge / Low level / Any logical change) to wake up from sleep mode. Sorry for the inconvenience caused.
Best Regards,
Manoraj Gnanadhas
Well done for getting that out of them Nick!
Good, because that is where I would look if I were checking!
It is also good to note that almost any form of interrupt would work.
Humm,
This is an interessting post, to be honest, I was using interrupt like that (and worked) without really have read the datasheet on this point. It looked to me so logical (and worked) that I missed this one, good catch.
By the way, while on interrupt post, I would like if possible to ask you guys on your high level of expertise on interrupt. I read all Nick dedicated post about interrupt on his forum (my godness this site is my most technical reference bible) and still have a interrogation due to strange thing happening on my ULPNode prototypes with IRQ and sleep mode.
Let's say I have this code (I simplified it from my lib)
// blah blah configure IRQ that could wake us (in my case INT0 and a Pin change)
volatile uint8_t counter = 0;
// we don't want to be waked by the watchdog, so be
// sure to disable it by changing the config
WDTCSR = _BV(WDCE) | _BV(WDE);
WDTCSR = 0;
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_enable();
// turn off BOD (sequenced order see datasheet)
// Don't change anything before we're waked
MCUCR = _BV(BODS) | _BV(BODSE);
MCUCR = _BV(BODS);
sei();
sleep_cpu();
// ...........
// ZZZZZZZZZZZ
// ...........
// Waked !!!
counter++;
nop(); // be sure to avoid compiler optimization changing 3*+1 counter increment to 1*3
counter++;
nop(); // be sure to avoid compiler optimization changing 3*+1 counter increment to 1*3
counter++;
I think while reading this code, your mind is already anticipating my question 
So my question is : what is the 1st instruction executed after wake up ? If I check counter in my IRQ which should have been the 1st instruction executed (well after the IRQ push stack overhead of course) I should always read it to 0 or is there a change that the IRQ trigger was delayed due to wake up and counter incremented before my IRQ was triggered ?
Really thanks for your help
Charly86:
So my question is : what is the 1st instruction executed after wake up ?
Call to the interrupt service routine vector which is nearly always a jump to the interrupt service routine. In your case, the vector for the watchdog.
Hey,
Thank you for your answer, that's what I thought, but sometimes, I saw strange things just like if my code was executed just before entering into my IRQ (the one who wake up me). But I have so much IRQ stuff in my project that it can be another thing. I think I will need to isolate one and write a small sketch with only this config and one IRQ. Then stress it with a switch push button to verify.