We actually have a utility
specifically intended to unambiguously identify whether or not you have the right ROM, and to provide necessary information for RHDN submissions.
I don't see why a 'hash' field entry for the ROM that works with a specific translation/hack would be a bad thing to implement.
This is exactly what the "ROM/ISO information" field is for, and it is required. However, submissions pre-dating this requirement will naturally be lacking that information.
We also aren't using hashes for security purposes, which means that although it is possible to intentionally create collisions with MD5, that has no implications in so far as ROM auditing/identification goes. The probability of a purely coincidental collision with MD5 is one in 3.40 × 10 ^ 38, or in plain English, one in a bajillion. The possibility of a random collision with CRC32 is one in four billion. All that said, SHA-1 is the preferred hash algorithm for submissions
. (SHA-256 is equally welcome.)
All that other information: HiROM/LoROM, country, Interleaved, SRAM, etc., adds a lot of noise and makes it harder for newcomers to properly locate and use the most important information. Aside from confusion on how to verify ROMs in the first place, the biggest point of confusion I see is related to headered/headerless SNES ROMs, but that is required information for RHDN submissions. After that is the issue that people seldom distinguish between a file hash (a hash of the entire contents of a file) and a ROM hash (a hash of plain, raw, uninterleaved/unheadered/etc ROM image).