When the scrutinizer walks (begin) it knows the returned value is
undefined.
The value or behaviour of (if (begin) 1 #t) is not defined by R5RS.
AFAIK if it's not defined then whatever the implementation chooses to do
is OK.
In this case the whole _expression_ can be therefore optimized to 1.
In my opinion, this is not a good direction for implementations of any language
to go. The Chicken community has been repeatedly bitten by the increasing
tendency of C compilers to do whatever they want rather than whatever makes
sense in the context of undefined behavior (the C equivalent of "is an error").
There are some great horror stories, like a null-pointer check being removed
from the compiled code because prior to the check the pointer was
dereferenced (which is of course wrong) and the compiler "knew"
as a result that the pointer could never be null. When it was, boom.
Similarly, printf-style debugging can be made unusable
if a printf is written just before a dubious
routine is called; if the routine is UB under all circumstances (as by using
a variable before initializing it), the failure can be hoisted above the printf!
In Scheme, whoever writes (begin) in a value context, even as a result
of macro expansion, is almost certainly making a mistake,
and the Right Thing IMO is to report an error, not to pessimize the code.
--
Promises become binding when there is a meeting of the minds and consideration
is exchanged. So it was at King's Bench in common law England; so it was
under the common law in the American colonies; so it was through more than
two centuries of jurisprudence in this country; and so it is today.
--Specht v. Netscape