We're probably drifting further and further off topic, but I would want it to behave differently.
While I could easily be wrong, I suspect that the current syntax is a result of lazy coding rather than one of intentional design. I say this because I've done almost this exact same thing. A couple years ago, I added an exists() function to a custom compiler/interpreter at our company. The function is intended to tell you whether a field exists in the current data set or not. However, fields in a function are always evaluated before the function is executed on them. If we try to evaluate a field that does NOT exist, the interpreter gives a run time error. Under time pressure, it was much easier to just pass in the field name as a literal instead of as a field name, thus avoiding the run time error. Literals in this compiler are in double quotes, so my syntax was exists("field") instead of the desired exists(field).
So it would not surprise me if peek('field'), applymap('mapping table',field) and the like are simply the result of time pressures to put out new features rather than intentional decisions to deviate from the norm. Perhaps, as in my case, reading in the field or table names as literals was a kluge to avoid more drastic overhauls to the core code of the system.
So what I would want in a feature request isn't a syntax error, but rather consistencey - literals in single quotes, field names in double quotes or brackets (or neither if no white space), search strings in double quotes, and so on. I think it is poor form to require putting a field name or table name in single quotes for occasional functions. I don't like seeing what I consider violations of a standard. It detracts from ease of use and so on.
