I dislike the other propsed metadata formats. For one thing, I think that
a device port should not be needed to be used for the metadata, and I think
that capabilities should be specified, and I have some other ideas.

The metadata can be either stored in the .rom file or in a separate file;
the format is the same either way. (You can store it in a separate file in
case you do not want to take up memory in the main program file)

The file starts with the LIT2 instruction, and then a big-endian 16-bit
number, and then a JMP2 instruction, and then some sort of identification
of the metadata format (a constant sequence of bytes, possibly a few ASCII
characters), and then the data.

The 16-bit number at the start is the address in uxn memory of the first
byte after the metadata block (equal to 0x0100 plus the file offset after
the metadata block). This can be used to identify the size of the metadata,
which can be used to allow extensions in future.

The above specifications also ensure that the metadata is optional and even
if it is present, emulators that cannot read it can still work, and without
using any device ports.

The metadata could include things such as:

* Metadata code page number (I partially made up a list of 23-bit code page
numbers; code page numbers less than 65536 are the same as assigned by IBM)
(use of purely ASCII (code page 367) should probably be encouraged, and
should be the default, for simplicity)

* Program title

* Author

* License

* Optional version information

* Capabilities (e.g. if it requires a certain input device or can use it
optionally, file system access, etc)

I don't know what else might be useful to include (if any).

Idea about the format: it could be a fixed format or maybe it is better
to use key/value pairs, each record being key, value length, value data;
although, should the key and value length be 8-bits each or 16-bits each?
The more things added, taking up more space, although if key/value pairs
are used then it also allows to omit any unused fields, saving space, but
the keys take up space too then and slightly less simple parsing.

Please make comment that it can be changed if necessary, before such a
thing will be implemented.

-- 
Don't laugh at the moon when it is day time in France.

I'll add a note to say that it's still a draft on the docs page, it's
very much in "flux" at the moment, I've only chosen this format to get
the ball rolling. I haven't seen many applications in the wild that
even supports metadata, so it's not too much a hurry to settle on a
standard, try some formats and metadata interpreters so we can try
them out :)

I don't mind using a jump instead of writing to the emulator device.
We can use that if you want.

I've been toying with the idea of grabbing the rom's "state" by
reading that vector and by changing the metadata, I can write a
different name to the emulator window title, like "Noodle -
neauismetica08x08.icn". I was thinking maybe it might be best to
specify port names for the emulator device(#f0) at some point to
handle these sort of events, but before moving forward with this I'd
like to complete the implementation of the manifest specs. I'd like to
be able to navigate the manifest from an external application, so this
will likely also find its way into the metadata.

I like the idea of the code page for the character encoding, it could
be located right after the position of the app icon. I'm not a super
fan of naming fields, I think it's best to let people use these 3-4
lines of data whichever way they want. Most of the apps I've written
use them for name, ver, details and credits, but it could be anything.
I'm also open to leaving the number of lines up to the application. In
potato, I read as long as it doesn't find two nulls in a row.

Try it out in your own roms and we'll play with them and experiment.
It's also just one metadata format, if someone want to use a specific
format for their roms and want to write a little gui tool to browse
the metadata I won't stop them and ask to use this or that metadata
format.