The startup code is currently just after the signature 'PRG\0' i.e. at offset 4.

But note that this is not part of any standard and is subject to change if features are added to the tool chain and the program loader. Tell me if you need any stable convention.

Not at all, this is a choice specific to Ndless.

Ok, so you'd like information for shells.

If the program format was to change, I would prefer to move towards a standard format such as BFLT or ELF, but I don't how this meta-data could be integrated to such formats.

That looks a lot like headers from Z80-series programs. Unfortunately, that is not very flexible. I would suggest the following instead:
struct header {
    char[8] "NdlessEx"; // Identifies program as Ndless executable
    void (*main)(); // Pointer to main entry point, or 0 if no basic main entry point is specified
    void *relocationData; // Pointer to relocation data block, or 0 if no relocation data is present
    void *metadata; // Pointer to meta-data block, or 0 if no meta-data is present
    void *debugSymbols; // Pointer to table of debugging information, or 0 if no debugging information is present
    int 0; // Specifies that no additional pointers are present in the header block
};Following the header block, no particular structure is imposed on the file. The main function, meta-data, debugging symbols, and relocation data can be placed anywhere in the file and in any order. There is no requirement for any of these blocks to be located immediately after the header block; programs can have functions or data after the header block if desired. Future standards may replace the 0 integer after the final pointer with additional pointers as needed.

To run a program, the Ndless loader will first examine the meta-data in the file, if present and necessary by future standards. Ndless will then process the relocation table, if present. Finally, Ndless will jump to the main entry point.

The main pointer may be null if the program has no main entry point. This could be because the program is actually a library, in which case Ndless may still need to perform relocation, and the library can present its metadata and debugging data in a standard format. This may also be because the program is not a raw Ndless executable, but based on the standard because, for example, it adheres to a later standard and should not be run by earlier Ndless versions, or is a shell-only program, in which case the shell will find the main entry point in a implementation-specific way (while still taking advantage of Ndless's future native relocation, meta-data, and debugging abilities.)

The format of the relocation data structure is not specified here. Somebody with more experience in that area may wish to define that.

The meta-data block should be XML-encoded using the encoding the Nspire prefers. The XML data block may be parsed using TI's routines. This data may be presented to the user by a shell. Programs may choose to read their own meta-data to, for example, display their own version information. Programs should include, at a minimum, Version, Title, and Author tags. Additional Author tags may be present for group projects. Additional tags may include Date, Description, Icon, and Copyright. The meta-data block is also a good place to place information on additional libraries needed, and minimum hardware, operating system, and/or Ndless version requirements.

The format of the debugging data structure is not specified here. This may become a part of the Ndless standard; or, the standard may simply state that debugging data is specific to a particular combination of compiler/linker and debugger, whether in-system or via emulator.

How about length prefaced?

Version number should go first, I'd think.

Or just use the ELF format. Tools already exist for it. Ndless would just need support for reading it.