I have a single issue that popped up around that time. Mame internally used to parse rom/parent/driver/default, but since then it has evolved into rom/parent/romof/driver/default. As a whole I don't think this really effects controls.dat much, but.... the question arises..... should the neogeo entry be renamed to neodrvr? I'm not sure if both work or which one overrides the other.
Hmm... I think of "romof" as "biosname". And IMO both "neogeo" and "neodrvr.c" are fine and on the same level. (I'm using the ctrlr file system names, which do need the dot cee to be include for the name to work.) AFAIK, all games that share a bios are in the same driver, and if one game in a driver uses a bios all of them use the same bios set (zip file). This puts the two on the same level, and neither are above the other.
One reason to use the driver name and drop the romof is all games have a driver, but not all have a romof. And since the two are near equivalent, dropping one shouldn't cause problems. And of the two, we can't drop driver name.
Of course, the name "neogeo" is more identifiable by users. And if the bios<->driver link ever is unlocked, it would be good to support both. But until the link is broken, we don't how it will be broken, so the exact hierarchy isn't set in stone.
As for why the hierarchy is so flexible, here's an example. Two companies, say Art & Way, team up and share a hardware system with only small differences. Each company uses similar but different bios, say BiosA & BiosW. Mamedev could group all these in the same driver, and group the bioses in one zip file. However, it's
possible that there's one driver & two bios files. Or for one bios file and two drivers. And for either to be split or joined in latter versions of mame, of course.
If anyone knows of any in mame, I'd like to hear if there are any real examples.
Anyway, I think ATM they are interchangeable, but we should support both ways if possible.