A not-so-small followup. Here are dumps of areas of interest from IGDM and SANV after a fresh bootup of debian 3.18-1~exp1 kernel:

IGDM.DIDL:

root@lx2netbook:~# { dd if=/dev/mem skip=$(( 0xCAAFB018 + 0x120 )) count=32 bs=1; dd if=/dev/mem skip=$(( 0xCAAFB018 + 0x1C4 )) count=28 bs=1 ; } 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" '
00000100 00000002 00000300 00000301
00000302 00000303 00000304 00000008
00000000 00000000 00000000 00000000
00000000 00000000 00000000 

IGDM.CADL:

root@lx2netbook:~# { dd if=/dev/mem skip=$(( 0xCAAFB018 + 0x160 )) count=32 bs=1;} 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" '
00000100 00000002 00000300 00000301
00000302 00000303 00000304 00000008

SANV.DIDX:
root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 315)) count=4 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" '
80010410

SANV.EDPV:
root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 310)) count=1 2>-| hexdump -v -e ' 16/1 "%.2X " "\n" '
02

SANV.NDID:
root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 232)) count=1 2>-| hexdump -v -e ' 16/1 "%.2X " "\n" '
08 

SANV.DID1 .. SANV.DID8:
root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 233)) count=32 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" '
80000002 80000100 80000300 80000301
80000302 80000303 80000304 80000008

SANV.DID9 .. SANV.DIDB:
root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 16)) count=12 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" '
00000000 00000000 00000000 

SANV.DIDC .. SANV.DIDF:
root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 101)) count=16 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" '
00000000 00000000 00000000 00000000


Looks like DIDX and EDPV were somehow initialized (maybe by EFI firmware prior to kernel bootup?) and EDPV value of 2 suggests that it was initialized in DD02._ADR method. It is not exactly clear why DIDX became 0x80010410. For the case when EDPV equals to 2 it should be that SANV.DIDX==SANV.DID2 (initialized in DD02._ADR). SANV.DID2 gets initialized in GFX0._DOD like DID2=SDDL(IGDM.DIDL). Method SDDL transforms DIDL like this: (DIDL & 0x0F0F) | 0x80000000. So it is unclear why is bit 4 is high in the first byte of DID2. The same stands for lowest bit of the third byte. Maybe it is controlled elsewhere either by the ACPI or by the gfx driver or by the hardware. 

What seems obvious is that IGDM.DIDL had changed at some point after EDPV and DIDX got initialized. Then the CADL had been "reinitialized" with a new values from the DIDL and the GFX0._DOD method had been invoked resulting in re-population of SANV.DID1..SANV.DIDF.

This findings are consistent through a number of different kernel versions, namely (debian kernels): 3.13.5-1, 3.14.15-2, 3.17-1~exp1 and 3.18-1~exp1.

With old and dusty 3.2.32-1 the behavior is different:

a) i915 fails to load with "[drmi:i915_init] *ERROR* drm/i915 can't work without intel_agp module!" message. This results in lack of kernel modesetting and X falling back to vesa driver.

b) Pressing Fn+F5/F6 at text console results in ACPI related messages in dmesg like:
Feb 17 20:26:08 lx2netbook kernel: [  342.302819] ACPI Error: Result stack is empty! State=ffff880224697400 (20110623/dswstate-98)
Feb 17 20:26:08 lx2netbook kernel: [  342.302996] ACPI Exception: AE_AML_NO_RETURN_VALUE, Missing or null operand (20110623/dsutils-646)
Feb 17 20:26:08 lx2netbook kernel: [  342.303169] ACPI Exception: AE_AML_NO_RETURN_VALUE, While creating Arg 0 (20110623/dsutils-763)
Feb 17 20:26:08 lx2netbook kernel: [  342.303342] ACPI Error: Method parse/execution failed [\_SB_.PCI0.GFX0.GCBL] (Node ffff8802260d8880), AE_AML_NO_RETURN_VALUE (20110623/psparse-536)
Feb 17 20:26:08 lx2netbook kernel: [  342.303607] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff88022609e920), AE_AML_NO_RETURN_VALUE (20110623/psparse-536)
Feb 17 20:26:08 lx2netbook kernel: [  342.303872] ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0F] (Node ffff88022609e8d0), AE_AML_NO_RETURN_VALUE (20110623/psparse-536)

c) CADL/DIDL are totally empty, i.e. are filled with zeroes. Meanwhile DIDX stays at 0x80010410, EDPV equals to 2 and SANV.DIDx are initialized to some interesting numbers:
root@lx2netbook:~# dd if=/dev/mem bs=1 skip=$(( 0xCAAFEE18 + 233)) count=32 2>/dev/null | hexdump -v -e ' 4/4 "%.8X " "\n" '
80010100 80010410 80016330 80017331
80017342 80016353 80017354 00000000

I have no idea what is the source for these and how to interpret then properly. Hope these findings would help people with more knowledge to track down the issue and fix it. 
I'm still open for trying some experimental kernel builds and am looking for guidance on this matter.