Great! Typo errors in printer templates or rule configurations is exactly a real life issue! Now it is interesting for me.
Possible solutions of this issue is what we really need to focus on and discuss.
Defining constraints for custom product tags might still can be a part of the solution. I don’t argue that. However having no predefined tag values is not the only source of this problem. I should properly define that…
Well, I don’t know about this honestly.
Personally, I like the way it works now. I can certainly understand why JTRTech feels differently, and I know why he wants it that way. I am all for standards certainly - coming from a DB architect/provisioner/reporter standpoint, this makes a lot of sense mostly for the very same reasons that JTRTech mentions - disallowing free-entry solves problems. I dealt with this in a major core system conversion and it had to do with standardization of how Customer details were stored for Address (and all parts of an address), Phone, First, Middle, Last Name, and it was a royal pain because address data for example was freely editable. How do you query on that and get reliable results? Answer: not possible.
However…
If we are to constrain GroupCode and Product Tag to a pre-defined list, then when need another config section to make this work. That’s fine. But leave me the option to constrain to that list, or not.
Why?
Because right now, configuring a Product is a single-card process; that is, I can freely create a new GroupCode and/or Product Tag on-the-fly when I create the Product. If you constrain them, then I need to go into the GroupCode section/Card, and the Product Tag Card, create the new GroupCode and Product Tag, then go back into Products to insert my new Product. This is far less efficient, especially for a lot of new Product setup, and it will probably break the Batch Entry option altogether.
OK…
This is true - I just happen to define allot of my configurations based around products in ways which all stem from custom tags on products.
I agree with QMcKay that to have this ‘fixed’ for all tags will increase workflow for new/frssh products on a system/batch creation.
This was where my original idea came in that product tags were defined in a similar way to the way we create entity custom fields.
Yes we covered that the data for entity fields is utilized in a different way but as far as I understand Entity Custom Data is sorted in the DB in exactly the same manner as custom product tags? am I wrong?
A string field or even the new ‘list’ product tags is a very basic way to set these invaluable fields.
If this were added in a similar way to custom entity fields you could define the type of field as to whether it was constrained or not and how it was constrained.
In my example I also suggested we might even have the option of a ‘tick box field’ which could be stored as a TRUE/FALSE value in the database and would give a very nice clean precise way to handle YES/NO product tags like my setup I have an ‘Open Price Tag’ which at the minute on order added if tag != ‘’ it prompts for price with a custom keyboard removing the need for a keyboard on the menu screen.
Also kitchen/bar print I have order added tag → state for is Kitchen Print Tag != ‘’ state of Kitchen Order (which gets changed to Kitchen Ordered) on ticket close.
This would remove the use of != ‘’ in allot of uses which is a slightly crude method and would turn to for example Kitchen Order Tag == ‘TRUE’ which is much more precise and professional.
So maybe asking confirmation while adding a new value can be an alternative solution. So you’ll notice when you use a non existing value and can easily confirm it without switching screens. We can even define a permission for non-admins so you won’t need to configure all possible values in advance and non-admins can’t add new values.
I’m not proposing a solution here. I won’t implement it 
I’m trying to explain when we define issue properly we can find alternative solutions.
That was a thought which came to my mind also 
…
You are, sort of. At least it is 1 idea for a solution. And I like it.
See, that idea is better than I expected the solution to be. We can have our cake and eat it too. My thought for the solution is short-sighted, and solves the initial problem, but it is not the best solution… that is why @emre is the master at this stuff, and thinking on a larger scale to produce something even better.