Not a bug, but you’re right; I’m not an expert on the matter but I’d say; do excercize some care when naming fields if you are going to use them for more than plain text references. Don’t user spaces or special characters like brackets, pipe chars, quotes…
A technique to scrub arbitrary strings to make them safer as fields is to run the slugify filter op on them.
The convention you use here is [operator-name[parameter]] … Since serving is no official operator, the parser assumes, that it is a field. So your example is a shortcut for [field:serving[3]]
I second @pmario’s advice and will add that in a field name, you should avoid any character which has a meaning in regexps, including forward slashes (/).
I got a lot of troubles with this in an avoided experiment on “fields namespaces”. My idea was to name “system fields” like system tiddlers, using a $:/ prefix. Don’t do it as it has all kind of nasty side-effects.