what you mean by further processing? Are you processing resulting jar by some external tools or within the container? If it's within Java code, you should be able to iterate directly on top the archive nodes/assets, so order should be irrelevant.
You can use dependencyManagement to override shrinkwrap version - by importing shrinkwrap-bom before, arquillian-bom, however using latest Arquillian without latest ShrinkWrap might not work as expected.
Please file a bug in SHRINKWRAP jira if you need to enforce a specific order in zip.
By further processing I mean that content of this Zip is processed by 3rd party library. This library relies on correct order of entries in the Zip file, as it tries to create directories from zip sequentially, as they are stored in the Zip file. Once it hits a directory which is already created (e.g. because a sub folder was already created in previous step) the whole processing fails. I'll contact developer of that library if he can implement support also for "unordered" zip files.
I also filed a new feature request to consider: [SHRINKWRAP-480] Fix order of entries in exported zip file - JBoss Issue Tracker
Thanks for help!