Hi Aeyr,
I've answered the 2N^1 issue in the other thread.
As for exposing FI (definitely a better option than linking directly I'd say), something like a buffer_SaveAsImageFile(buf, width, height, format, filename) and a buffer_LoadFromImageFile(filename) would be fantastic.
Before I launch into my answer proper, I'll just be pendantic for moment and state that L3DT and the API don't have functions for handling I/O of images specifically; they are treated as just another map file format.
Anyway, the functions you mention would either require plugin developers to write more code in the file I/O plugins (in addition to map/tile support, they would have to add buffer support), or else I would have to map the buffer_ functions via the map_SaveFile/map_LoadFile functions by copying the map data to/from the buffer and calling the plugin map load/save code. This is kind of messy, and I would think unnecessary, since the map class gives you the same functionality of the buffer class (although the map class doesn’t expose the low-level buffer handle.)
Is there a reason you want to access image data as a buffer, and not, say, via map_GetPixel/map_SetPixel? If so, would a function like LPVOID map_GetMemoryDirect(ZMAP hMap) work for you? Obviously this won't work with mosaics, as the data isn't stored in a single buffer, but to access mosaic data you have to use the GetPixel/SetPixel functions anyway (they wrap the code for handling the tile cache.)
Cheers,
Aaron.