I would propose that you save each group with a randomized identifier string, with "name" as one of the properties. This way rules can be attached to that unique string and simply display the 'name' associated with it, even if that name is edited on the Rules page.

I believe it would look something like this in LiteMount.lua:
`["57974002-d9e7-46f2-a73d-7c4eccf55ede"] = {
[Name] = "Race-Highmountain Tauren",
[288712] = true,
[258060] = true,
[213339] = true,
[242874] = true,
},

["rules"] = {
{
"Mount [map:203,submerged] mt:232",
"Mount [map:1355,flyable,qfc:56766] mt:254",
"Mount [instance:531] mt:241",
"LimitExclude ALL",
"LimitInclude [race:HighmountainTauren] 57974002-d9e7-46f2-a73d-7c4eccf55ede",
"Mount [extra:202477,nosubmerged] id:881",
},
`

I mean. Why though?

Rules currently match to Groups by the group name. If you rename your groups for any reason, it breaks the rule(s) using that group and they all have to be edited to use the new group name.

Using a UUID in this way the group name becomes an independent property, so when you rename a group it'll still be connected to the Rule and the Rules tab would simply display the updated group name.

Having said all that it is still an annoyance that renaming a group breaks the rules.

I obviously never did this, but I also forgot to write down my thoughts.

The first and most obvious is that the groups are a constrained very small set. So using globally unique ID is massive overkill, may as well just number them from 1 and use that (groupID). The only advantage to the GUID would be if there was a mechanism to export and import a groups+rules set, even even then the translation is straightforward.

Groups are used by name, by hand, in the advanced options action lists. Not just in computer-read rules. I'm certainly not going to make people remember and use the group ID there, so at minimum everything would have to support both, and there would need to be some kind of GetGroupByName() GetGroupByID() interface. And some protection to prevent duplicate names. Or worse some kind of OO group and object-store-mapping, extra caching to make it perform, etc.

Also this is a negative for debugging people's problem. From the example:

 "LimitInclude [race:HighmountainTauren] 57974002-d9e7-46f2-a73d-7c4eccf55ede",

takes extra steps to comprehend. Probably not a big deal but a factor.

The only problem this addresses is "renaming groups in rules" (unless you include my compsci prof would give me a better mark for neatness and orthogonality). It doesn't even fix the problem of renaming groups in action lists without forcing action list authors into a hugely worse interface. So far it doesn't seem worth the dev effort, and might in fact be better to just do the renaming in rules too.