I would strongly recommend that you use the AFNI functions for reading data. However, if that is infeasible, then

a) The filenames are of the form prefix+view.suff, where prefix is at the user's discretion (no blanks or control characters, though), +view is one of "+orig", "+acpc", or "+tlrc", and .suff is one of ".HEAD" or ".BRIK". AFNI also allows the .BRIK filename to have ".gz" appended, which means that it is compressed with gzip. AFNI will decompress these on-the-fly as it reads them (by piping through "gzip -d").

b) I don't understand this: what implications or links there to file names in the header file? The .HEAD and .BRIK filenames must match, since AFNI programs use the .HEAD filename to construct the .BRIK filename. The .HEAD file no longer must contain any filenames. Other datasets are referred to by their (hopefully) globally unique ID codes.

c) ID codes are pseudorandomly generated in the source file niml/niml_uuid.c, if you want to check that out. They are strings of up to 31 characters (plus the C NUL at the end). The current code uses only characters from the alphabet (uc and lc), digits, plus underscore and hyphen (64 distinct characters). With this limitation, an ID code could be used as a filename, for example (although I never do so). The method used to generate these strings is described in the comments in niml/niml_uuid.c, at the top of function UNIQ_idcode(). You can use the AFNI command 3dnewid -fun 10 to see 10 ID codes at a time. The Unix environment variable "IDCODE_PREFIX" is used to set the first 3 characters of the ID code, if present -- if this variable isn't set, then "XYZ" is used. This allows a user or institution to customize the ID code with some initials (e.g., "NIH").