Thank you for your thoughtful response to the format revision.

We have taken aboard you comments and made changes to the revised format (the original message in this thread has been edited appropriately).  In particular, we agreed that it seemed necessary for consistency to have slice_start and slice_end set to int64_t.  In addition, and to ensure 8-byte alignment, we have upgraded the other fields to int, except for datatype which we feel still has sufficient capacity (with at least 240 codes still left, and there being a limit to how many different types of data might be stored without requiring extensions to decode the datatypes).

The code range for the custom codes is still to be defined, but it is likely to be a limited range (and not set bitwise) since the use of custom codes is only encouraged as a very temporary measure, with the expectation that useful elements will be registered and obtain official codes.  Otherwise there is a risk of the format becoming less open and accessible for all users. 

As a consequence the header is now 540 bytes + 4 bytes for the initial extension info (total of 544 bytes).

The unused_str will be forced to be filled with \0 characters.

Finally, in answer to your last question, the quatern_a is still stored in the same way (via pixdim[0]) in order to retain the same logic as NIfTI-1 and make the implementation change easier for developers.  I fully expect that future formats will not follow this scheme, and this should be raised in that forum, but for now it is the most consistent and simplest way of modifying the existing format.