I didn't realize it, but Carl had written a Rebol 3.0 Blog post which was speaking to the security issue of leaking values:
http://www.rebol.net/r3blogs/0025.html - "Leaky Functions"
He says "Of course, we cannot change the default function return case (as shown in the first example) because it would break far to much code."
Reactions From The Comments
Brian Hawley predictably says that this could be driven by a setting.
Sunanda has the weird suggestion this be a feature of a function being in a module... since modules were new, any code in the modules could obey the new rule: "That does not need any additional syntax at all.....Simply document that a function in a module always return (say) NONE if it has no explict RETURN value."
Gregg points out that having FUNC behave differently in modules would be weird, and what if you composed the function across a module boundary.
@Brett has an interesting remark that is probably worth a post considering it here in the module category: "Re-reading module blog entry and this front line entry leaves me wondering if limiting of access to module words is enough. For super security should values (like block!, string! and issue!) be tied to a module too. If a non-exported value was about to be leaked it could converted to an error. Modules then are not just a namespace, but a memory space."
Jaime suggests a separate PROC function generator.
Oldes says break it, none of the code is going to be compatible anyway.
Funny Enough, I Agree With Oldes This Time
Ren-C actually did add PROC, but at a time when there was both FUNC and FUNCTION with different semantics, there was PROC and PROCEDURE with different semantics.
What ultimately soured me on the idea was that any time you created something "function-like", e.g. METH and METHOD, you face again the idea that you have to find some way to name the version that returns a value or doesn't. ("METHPROC" and "METHODPROCEDURE"?)
Ultimately FUNC and FUNCTION were unified as synonyms, making it even easier to make FUNC-like things that put all their behavior cues inside the spec block.
Anyway, it was interesting to see this discussion that I didn't know had happened. But Ren-C really clinches the issue since each function's localized RETURN can be hooked or replaced. You don't want values falling out the bottom of the function to be exempt from whatever finalization RETURN might be intended to do.