@bguerville: If PKG file format contain encrypted data, then PKGS are ZIP but with the same content. Comparing to VPKs which are ZIP with not encrypted content. Well, at least this is how I understand this. And to be honest, I don't really see a point to rename ZIP into VPK or PKGS...
Comparing to PS3 world: PKG for PS3 have not encrypted content (besides EBOOT/SELF/SPRX, right? or they are just signed and/or compressed?).
Many apps rely on compression libraries internally, I use 7z & ace regularly at work. It makes no sense to reinvent the wheel. Developers usually choose the best library for the app specs.
I believe there is a huge difference between pkg & pkgs.
It is my understanding that a pkg file is not a zip container, it does not rely on the zip standard for its own structure, it uses Zlib compression to inflate the archived files if compression is chosen during the creation process. If compression is not used, the pkg will be created without calling the Zlib library at all.
If I am not mistaken, the pkg content is encrypted with AES128 for metadata + data & AES256 for metadata header. You cannot read or create a pkg file with a zip utility. Pkg files are not zip compliant files & are not meant to be.
Pkgs are just renamed zip archive files. They can be read & created with a zip utility. As a matter of fact, this app uses a 7z executable to compress the data & create the archive file. There seems to be no encryption used though.
That is why it makes little sense to use a different extension.
Regarding encryption, let us not confuse pkg encryption with the standard file encryption used by s#ny for its executable & licence files. bin/sdat/sprx files are all possibly encrypted & compressed (via scetool).
This has nothing to do with pkg files.
A pkg can also be encrypted & compressed (and generally is) but it is done independently from the encryption/compression status of its contents.
Don't get me wrong, any development effort is a worthy effort imho... This is not criticism, just a friendly comment.
