There's a feature in modern Ren-C which is that if you use arity-0 return, you get a TRASH! which has the name of the function.
>> foo: func [] [return]
>> foo ; will have no console output, because it returns TRASH!
>> lift foo
== ~<foo>~
The same happens for PROCEDURE / PROC when you don't use a return:
>> foo: proc [] []
>> lift foo
== ~<foo>~
I'll point out that if you pass an actual TRASH! to a function's RETURN, this will be taken verbatim and its name not changed.
>> bar: func [] [return foo]
>> bar ; no console output, returns TRASH!
>> lift bar
== ~<foo>~
So you get different behavior from bar: func [] [foo, return] (or bar: proc [] [foo]) which would give you a ~<bar>~ trash.
Not twisting an explicit value you're passed makes sense to me. (If you happen to be piping some other function's return result and want a TRASH! return to be twisted into the name of the function doing the piping... that is possible to write, but I don't think the system needs to offer a pattern for doing that out of the box. It's rare to want to do that--and even rarer to care what the symbol in the trash is.)
C doesn't let you write return in a function that is supposed to return a value, you have to return something. And when you say return and pass it a particular TRASH! value, that will return the literal trash you specified... hence not getting the "use the name of the function" feature.
We could say that return ""; means arity-0 return, and it could thus generate a TRASH! with the name of the native.
I've speculated on this question before regarding what should transcode of an empty string be. If we say that transcode of an empty string is legitimately an empty block, that might suggest that return "" would have to do the same thing as return "eval []".
This shows some actual value in considering emptiness "out of band" for transcoding, which may be worth revisiting my decision and saying that there's a special result for transcode of an empty string. Maybe that result shouldn't be NULL, but some other signal that would be differentiable from the null you'd get from try transcode when it's an error?
I'll have to think about it.
(Sidenote: JavaScript allows you to leave off the return value in any function (there's no 'return type' concept and hence no distinction of void and non-void functions). But you can't tell the difference between return and return undefined;)