ONLY_FULL_GROUP_BY SQL MODE".

The root problem is that ONLY_FULL_GROUP_BY mode raises
an error on
 SELECT (subq) GROUP BY (same subq);
It does not recognize that both subqueries are the same.
Fixing this root cause is too difficult:
it would require implementing Item_subselect::eq(); and it's not worth
the effort because:
a) GROUP BY (subquery) is non-SQL-standard so is likely of
very little interest to users of ONLY_FULL_GROUP_BY
b) as the user uses ONLY_FULL_GROUP_BY, he wants to have the
same subquery in GROUP BY and SELECT list, so can give the
subquery an alias in the SELECT list and use this alias in
GROUP BY, thus avoiding the problem.

Back to the bug report: a view is created as
 SELECT (subq) AS field2 GROUP BY field2;
Such SELECT, when run standalone, is accepted by ONLY_FULL_GROUP_BY.
But when used in a view, the SELECT is written to the view's
frm file (= what will be the view's definition) as:
 SELECT (subq) AS field2 GROUP BY (subq);
and thus, when the view is later used, it bumps into the
"root cause" above, and so
 SELECT * FROM the_view;
causes an error in ONLY_FULL_GROUP_MODE.
To avoid bumping in the root cause, we now
print to the frm file:
 SELECT (subq) AS field2 GROUP BY field2;
More generally:
 SELECT expression AS alias GROUP BY alias;
is now printed as
 SELECT expression AS alias GROUP BY alias;
instead of
 SELECT expression AS alias GROUP BY expression;
This is done by following this logic, when printing the
ORDER BY or GROUP BY list: if, in this list, the item was referenced using
an alias, then print the alias, not the item's expression.
This is, after all, closer to the original query, which is a good thing
per se.
Note that we do not change the case of
 SELECT expression AS alias GROUP BY same_expression;
which is still printed as
 SELECT expression AS alias GROUP BY same_expression;
Indeed, printing alias in GROUP BY could yield ambiguity (see last test in
group_by.test).