We can disentangle what is going on at the low level. First of all,
shift is defined as
The macro that does the heavy lifting scanning a point is
\tikz@scan@one@point. The result is a
\pgfpoint which is then passed to
\pgftransformshift. This transformation is then added to the stack of transformations which is managed by
The procedure of
\tikz@scan@one@point is a bit more tricky. Here is a tree diagram of what happens inside approximately.
if next character is +
scan relative point |
if next character is + |
/yes no\ |
relative to previous relative to first |
\ / |
scan absolute point --------------
if character is (
| expand tokens (at most 100 times)
| valid coordinate found?
| /yes no\
| | Give up.
| | "Cannot parse this coordinate"
-- if next character is [
scan until ] and pass to \tikzset |
if next character is $
<--- calc library |
if coordinate contains with cs:
parse coordinate system |
if coordinate contains intersection
parse intersection if coordinate contains with |
if coordinate contains -| |
/yes no\ |
parse -| specifier parse |- specifier |
if coordinate contains :
parse polar coordinate |
if coordinate contains ,
parse regular coordinate parse node name
In your case it will descend into the
parse regular coordinate branch, where the point will just be split at the comma and each component will be evaluated with
Regarding the second part of your question:
And if I want to define a pgfkey with a coordinate-like parameter so that when I pass a string like (2, 3, 4), it is parsed and the values are saved to three macros respectively, is it feasible to imitate the way how tikz handles or are there some other convenient methods?
In this case I think you are better off parsing this by hand, i.e. something along those lines: