BUG - Different Cloud vs. Desktop Return behavior in V13.1

Question

After install V13.1 one of my scripts get broke in my Mac. Here is the bug:

Module[{}, Return[1]; 2]

Return[1]

When I tested in Wolfram Cloud I get the expected/old result that was 1 instead of Return[1]

I see it as a serious BUG, as It breaks compatibility with V13.0 and has inconsistent result between Cloud and Desktop.

It's a BUG? Should I change my code to the ugly/safe form: Return[arg, Module]?

Cross post in Wolfram Community

PS: This was what I call a Pseudo Version Update Bug, It's a bug that you believe was the version update, but It was not. The code break was not generated by the Return, but the inconsistence between Cloud and Desktop exists.

Answer 1

With versions 5.2, 8.0.4 and 12.3.1 on Windows 10 x64 I get the same result:

Exactly this aspect of Return behavior was earlier discussed in the following thread:

• How does Return work?

In this answer (from another thread) Chris Degnen provides a link to this 2009 year MathGroup post by Leonid Shifrin where he argues that this behavior isn't a bug:

My feeling is that this is not a bug.
There are two possible outcomes for any expression wrapped in Return: either
it is inside some lexical  (or dynamic) scoping construct for which the
action of Return is defined - and then Return disappears as a part of
breaking-out-of-the-scoping-construct procedure, or it is not and then it is
just a symbolic expression like any other.  It seems like neither Function
nor CompoundExpression  are  considered  by Mathematica as the scoping
constructs for which the action of Return is defined as for example for
Module, Block, With, etc.
Under this assumption, your puzzle can be reduced to a simpler one:
In[1]:=
Clear[a,b,c];
c=(Return[a];3)
Out[1]= Return[a]
In[2]:=
b:=(Return[a];3)
In[3]:= b
Out[3]= a
The latter discrepancy can be explained by consulting the exact rules of the
evaluation procedure. Lacking a more up-to-date account, I cite here David
Withoff's "Mathematica internals" of 1992:
The very last step of the evaluation loop is (Chapter 3 - evaluation, p. 7,
on the bottom):
"Discard the head Return, if present, for expressions generated through
application of user-defined rules."
Thus, when you use SetDelayed, you create user-defined delayed rule and then
Return is discarded, while for "direct" evaluation like
In[4]:= Return[a]
Out[4]= Return[a]
it is not.
At least, things seem to work as documented in Withoff's technical report.
One thing that would be nice to have is a complete list of scoping
constructs for which Return is discarded when whatever it is wrapped around
is returned from that scoping construct.
Regards,
Leonid

Also, a telling comment by Daniel Lichtblau:

I know at least one developer who would require psychoanalysis, possibly forensic in nature, were he to ever again try to carefully consider the inner workings of Return. – Daniel Lichtblau Sep 28, 2016 at 19:09