Just to expand on the information given in this thread, when you have conflicting registry entries in the RGUs of your kitchen, the one parsed last is the one that will make it into the final rom. By using a UUID starting with f's in the first group of the UUID, your rgu in that package will be parsed towards the end, effectively replacing any conflicting registry entry you want to replace/update.
Another method of updating registry values is by using a minus sign after the opening bracket of the line, but this is not the preferred method in this application, as users may inadvertently remove an entire key when just trying to update one value. The f's naming convention is the way to go.
A UUID is usually assigned randomly or based on the time it was generated or both. In the current variant used, there are 5 versions used.
- Time-based with unique or random host identifier
- DCE Security version (with POSIX UIDs)
- Name-based (MD5 hash)
- Random
- Name-based (SHA-1 hash)
You can find out which version is being used by looking at the first digit of the third group. For example, the tools some choose to use include the new oemizer and oem helper. Both tools use random generation, as demonstrated by a25ba3df-785a-4a9e-8dd4-b89d9f519e29. As you can see, the first digit of the third group is a 4, so it is random.
Anyway, this is probably way more than you ever wanted to know about UUIDs and how RGUs are processed and why, but figured I'd throw the information out there for those who care.