[Track] - was just trying to make it more foolproof for fools like me.
The problems there are:
1. Where does it end?
The parser uses a system, and the system has to have rules you can understand. The square brackets denote, throughout the application, field names.* There are, of course, plenty of places where you might not "know" the field name exactly. Is it [Bit Rate] or [Bitrate]? Is it [Bit Depth] or [Bitdepth]? (Latter, and then former.)
Or, what about ambiguous names? Does [Remark] (which is invalid by default) mean [Comment], [Description], [Caption], or nothing?
2. Conflicts.
What if I made my own, real, [Track] field? Perhaps I use it as a checkbox field to decide whether to "keep track of" a file in a system or not? What if they decide that [Remark] equals [Comment] but I want to make my own [Remark] field (or already have)? If they implement these arbitrary rules, there won't be a way to "look it up", you'll just have to memorize them. And how could they not conflict with someone's custom fields somewhere?
Remember:
You can always look up the current names in the Library Field Manager, as described above, or use the drop-down selector as mentioned by 6233638. In any case, I doubt you'll make this
particular mistake again!
* With one irritating exception.