While reading this answer I feel confused. If we do not care any specific detail of the original question, then ybeltukov's answer essentially makes use of the following fact
h_[a___, G[x_, ___, y_], b___] ^:= y[x] G[2, e] e[2]
This example shows that unlike Set, SetDelayed, TagSet and TagSetDelayed which imperatively require that the assignment is associated to some symbol called assignment tag, UpSet and UpSetDelayed can be used to make assignment associated to pattern object as well (like the h_ in this example).
However, when executing G[2, e] it seems that the evaluator treats the flat input G[2, e] as ghostHead_[G[2, e]] such that the user-defined UpValues for G can be applied.
I cannot understand this. I assume there is some very fundamental mechanism taking effect in this example. Could someone point out the missing knowledge?
Edit
I am also confused about the use of Simplify in ybeltukov's answer. Why Simplify can reduce G[2, e] to e[2]? I have not found any documentation revealing this.
Edit 2
As Szabolcs points out in the comment, because the StandardForm is by default used by the Front End for output, the plain input G[2,e] is evaluated to G[2,e] then wrapped as
StandardFrom[G[2,e]] which applies to the UpValues defined by
h_[a___, G[x_, ___, y_], b___] ^:= y[x] where, according to the standard Wolfram Language evaluation process, the UpValues of G is used prior to the DownValues of StandardFrom, so that the DownValues of StandardFrom is shadowed.
This is a side effect of the Front End wrapping StandardForm to the output, but we may make use of it.
We can also understand ybeltukov's answer which is,
h_[a___, G[x_, ___, y_], b___] ^:= h[a, y[x], b] Simplify[G[2,e]] e[2]
where Simplify also acts as a wrapper whose DownValues is also shadowed, and according to the upvalue definition, Simplify[G[2,e]] is evaluated as Simplify[e[2]] which further reduces to e[2] according to the definition of Simplify.
With such understanding, we can replace the Simplify with StandardForm,
StandardForm@G[2,e] this will return the same result but with better efficiency, because StandardForm does not require searching for applicable transformation rules.
h_[a___, G[x_, ___, y_], b___] ^:= (Print@Hold@h[a, G[x, y], b]; y[x])$\endgroup$G. The example you show creates an up-value ofG. So how comeG[2,e]evaluates at all? Since the definition is an up-value one,G[2,e]should only evaluate if it is wrapped by some head. Here it appears it isn't. What really happens is that as part of formatting, the FrontEnd does wrapG[2,e]in another head, which then triggers the UpValue evaluation. Running this example in a terminal, with no Front End, does nothing:G[2,e]doesn't evaluate. $\endgroup$h_to some certain symbolh, ie,h[a___, G[x_, ___, y_], b___] ^:= (Print@Hold@h[a, G[x, y], b]; y[x])then the previous resulte[2]is not obtained. This shows that the Front End picks theghostHeadit wraps toG[2,e]. There must be some mechanism used by the Front End, but the purpose is hidden. $\endgroup$G[2,e]simply evaluates to itself. But the Front End will format every output as StandardForm by default. This formatting goes wrong and yieldse[2] due to the UpValue $\endgroup$