What I'd be more interested in is - how is it either going to be simpler for the user, or allow doing stuff that isn't possible otherwise (taking into account that a single level will be able to use multiple graphic sets if desired)? I had considered splitting them into seperate files, possibly organised via folders (to create something similar to a graphic "set"), for each piece (but the files themself would still be a NX2-specific format, so that all the various images as well as metadata for a piece are contained in a single file), but I'm not seeing any huge advantage in this. On the other side, I could see it causing problems if - say - a user makes a pack that only uses a few pieces out of what's meant to be a "graphic set", and thus when they distribute their pack, other users (who may in turn want to use this set) end up with only parts of the set, rather than the full collection (which is not possible if graphic sets are maintained).
Sure, a directory structure might be a tiny bit simpler to implement on the programming side of things. But I can see it causing a lot of hassle for end-users that a proper graphic set format would not. One possible compromise is to support both, and that is already something I am considering - that way a graphic set can exist as a collection of files during development, then be packaged into a tidy single-file format for distribution once it's completed. Since the decision has already been made not to restrict use of content, if someone really wished to have it in directory structure format - either due to wanting to make changes to it (though for obvious reasons I'd advise using a new name in such a case), or simply because they would rather other formats were not used - it'd be completely possible to convert it in the editor. A similar thing is already possible with the existing NX1 graphic set tool, with the catch that NX1 can't directly use the directory structure (rather, the tool has to be used to convert it back to the NX1 native format first), and I have indeed found it useful during development of graphic sets - but very little reason to continue using it for a finished set. Since NX2 is being designed in such a way that support for extra formats can very easily be added, it would be little (if any) extra work to support directly using these formats, compared to a setup where they can be imported/exported but not used directly.
EDIT: At any rate, this kind of dicussion should be going in the Graphic Sets topic, not this one... compression is the issue for this topic; which would be equally relevant if stored as single pieces (but quite possibly less efficient in such a case - not sure exactly, I'm not overly familiar with the inner workings of ZLib). Yes, it would be irrelevant if PNG is used as the format - which it most likely would be used as the primary one (with BMP and maybe GIF supported as alternatives) for a directory structure based format, but even if graphic sets are split into single files per piece for the native format (which is a decision I'm unlikely to go with), PNG would not be used there; it'll use the same image format used everywhere in NX2 for the image sections of the data, which is simply a width, a height, and 32-bit pixel data for each pixel; which might then get ZLib compressed. No extra headers, support for various bit depths, padding, or anything like that - this is about as simple as it can be kept.