Unless I never looked at the name except in the source code, I don't see the much point in having
two names that can be distinguished (due to hashcode inclusion) but have been semantically
disconnected from the source code rules. If an error occurs in one of those rules, how will you know
which one the message refers to? How will you make sense out of the log? It makes more sense to me
to replace non-alphanumeric characters with alphanumerics as Ron's team member proposed.

Yeah, it's true that including a hashcode allows you to go from the "real" name to a unique generated one, but doesn't really help you go back the other way, unless you ALSO store the original name as a string in the rule, where you can use it to refer to the rule by name in exceptions and so forth.

An alpha replacement could be difficult given the number of potential non-alpha characters.

The other option, probably more work, would simply be to improve the validation and error reporting such that it was clear which two special-characters-included rules conflicted, and why they conflict.

e.g. "RNR Qty == RNR Adjustment Qty : 100% Tolerance" has the same translated rules name as "RNR Qty >= RNR Adjustment Qty : 100% Tolerance"; please rename one of these rules.

That'd make the problem a little more clear, but I don't like it as much.

Anyway -- I'm not writing the code, so I'll just let Edson et. al figure it out. :)

- Geoffrey