SET-WORD! in func spec are "true locals", permit RETURN:

[hostilefork]

While implementing the native FUNC and CLOS generators and
needing to work with adding locals, it became apparent that finding
and managing the relationship with /LOCAL was unnecessary overhead.
It also brought another instance of a "special" word into the system...
at the same time it was ensuring RETURN was not special.

(For the record, there was no SYM_LOCAL reference internally prior
to the definitional return work...so it had to introduce it.)

With definitional returns finished, this takes a step back on that and adds
a more useful feature. SET-WORD! in function specs are "true locals".
This means that they will be bound and will be in the function frame, but
will be invisible to and un-injectable by the outside world. They will not
appear in WORDS-OF or other outside inspections.

(Note: By saying that they "are true locals" this is to say that is the way
that they will behave as far as a pure MAKE FUNCTION! is concerned. A
generator similar to FUNC or any other non-function-making-looking-thing
can pre-process and give them entirely different meaning before passing
down to MAKE FUNCTION!. --This is an important point.--)

There are no rules on where in the function spec a true local appears...
it is skipped when arguments are being gathered. This makes it useful
for function generators that wish to add words but do not want to worry
about the position.

By convention, users may prefer to continue using /local...and there are
good reasons to do so if one is not a generator. For instance: if you are
defining one function inside another, you may not want to burden your
frame with locals because a function you defined is using set-words.

This lines up with Red's choice to use RETURN: for function in the
sense that a RETURN: is not a signal disabling definitional return, and
it is planned that a leading block in a spec before any ordinary words
will count as a return typeset. So foo: func [return: [integer!] ...] [...]
can idiomatically be a way of writing function specs, even though Ren/C
effectively considers the return: to be documentation (you could spell it
wrong and it would just give you another local by that name, as well as
a proper definitional return.