If NDK applications were staticly linked with libcutils and libc, then yes, they won't work. The shared libraries could be changed to emulate the previous behavior, but, admittedly, that's starting to get a bit extreme to change open and ioctl to strip off the ashmem operations and emulate them.
Changing the ashmem_* API implementation would be the most straightforward, and would address most applications. Those not using the ashmem_* APIs, or using a static library version of libcutils, deserve what they get, particularly taking heed of the NDK warning about which APIs are stable. If an application uses a static library, they should set the maxSdkVersion attribute, as they are likely to get broken in some future release. But, the ashmem APIs will need to be available essentially forever in the library, although the ashmem header file could be removed in future NDK releases, assuming the new service was implemented in the kernel. The user/kernel dependencies are still somewhat nebulous. While ICS devices are generally built with a 3.0 kernel, the emulator still runs under 2.6.39, so the flag day might still take an additional platform release, or the ashwin implementation would need to know the capability of the kernel. The Android ROM hacker community is generally still working with 2.6.36 kernels, particularly for non-OMAP devices.