I wrote one a few years ago as well. It read layers, summary image, and some layer metadata that I needed (blend mode, layer name, visibility flag, etc.). There's documentation for the format on the adobe site, I think (wherever it came from at the time - autumn 2007 - no fax was required), so it was actually fairly straightforward. An artist made me a bunch of PSD files with the stuff in that they wanted to use, and I sat there comparing the results of my code to what Photoshop did.

The only oddity I can recall is that Photoshop does something odd with the alpha channel - I think it was the alpha channel? - by sometimes storing it with the summary image rather than the layer to which it's related. (Don't ask me for more details than that - I don't remember.) I thought at the time that this looked like somebody's attempt to make newer data work tolerably with older revisions. That part WAS annoying, because the documentation didn't mention that, and it took about a week before somebody managed to create a photoshop file that was arranged this way.

The file format overall bore many of the hallmarks of one that had grown rather than being planned, but it looks like they'd started to clamp down on things at some point because the newer data chunks looked a lot better-designed than the old ones. These things happen. It could be worse. BMP is worse. TGA is worse. They aren't even chunk-based.

> Things were padded to 4 byte boundries because the 68000 processor would crash if you read an unaligned 32bit value.

It is actually padded to 2-byte boundaries. The 68000 had an external 16 bit data interface. That's the only thing I would fix about IFF if I redid it today. (And I would add a 64-bit length extension, and a "reserved chunkid" designation, e.g. anything that starts with a '$' must be registered in some central registry)