RETURN has been changed to be arity-1 or arity-0. If you don't pass it an argument you get a TRASH!.
Rather than overriding arity-0 RETURN to do something besides return TRASH!, I think it's probably better to have it take an argument which indicates it's doing more than that.
Something along the lines of "I'm returning a value...but it's something predetermined, or calculated elsewhere".
foo: func [x y z] [
return*: adapt return*/ [
assert [value = <calculate!>]
value: (something x) * y + (something-else z)
]
...
return <calculate!>
]
This is a particularly interesting style of return specialization, where you are essentially "dialecting RETURN"... you can come up with your own mini-language for what returning means.
I use something like this pretty heavily in the console implementation. You can make calls to EMIT giving code you want to queue up for the system to execute in "protected mode" (e.g. not nested under the console code itself), then when you say something like return <prompt> that is a way of saying "execute all those emitted lines, and then when done give the user a prompt again". But if you said return <die> that means execute the pending emits and then exit to the OS with an error level.