So the question of "how to show local proxies in the function spec" comes up... and I wonder if using SET-WORD! is a good idea or a bad one. (?)
Additional SET-WORD!s have no meaning to FUNC, but to a COMBINATOR that's generating a FUNC it can pick any convention it wants...since it's mutating them into locals.
It's not the worst concept, to use SET-WORD!s. But it's a bit weird that RETURN is a function while SECONDARY is just the name of a local that gets proxied into the results, that you assign via normal assignment.
One horrible suggestion would be to use a leading slash on RETURN to denote its distinct status as a function:
multi-returner: func [
/return: [integer!]
secondary: [integer!]
][
secondary: 20
return 10
]
That's a "cure is worse than the disease" idea if I ever saw one.
Since the output arguments manifests as local, maybe it could go inside a FENCE!?
multi-returner: func [
return: [integer!]
{secondary: [integer!]}
][
secondary: 20
return 10
]
That's clearly bad, as it looks like it's assigning the BLOCK! to secondary vs. type-constraining it.
Maybe the CONSTRUCT dialect is liberal and leaves a few things open to interpretation vs. trying to define everything... like TAG!, maybe?
multi-returner: func [
return: [integer!]
{<secondary> [integer!]}
][
secondary: 20
return 10
]
Eeerrrrhhhg. 
It may be a good idea to not completely saturate CONSTRUCT's dialect space so that higher level constructs can get creative in augmenting FENCE!. But I don't think this is a clarifying step up from using a SET-WORD! in the outer scope, even if that looks "like a return".
HEY, Wait. I Have a Winner...
multi-returner: func [
return: [integer!]
{secondary}: [integer!]
][
secondary: 20
return 10
]
"I am a local, but I am also used as a proxying output."
That's my favorite so far. It helps shift it into another category where your expectations are different than of a return function.
Should This Be A Built-In Feature?
Above I'm writing that as if FUNC understands it, when in reality I was talking about a feature that was specific to COMBINATOR.
I don't think it makes a lot of good sense to try and put meaning on that by default. Because as the COMBINATOR case shows, the "main return" actually becomes the second output.
It's easy enough to write your own proxying function generators that I don't know how much value making one that's in the box has. But if there is, it should probably be called MULTIFUNCTION (MULTIFUNC) or something like that.
I guess you could put things in whatever order you wanted:
multi-returner: multifunc [
{secondary}: [integer!]
return: [integer!]
][
secondary: 20
return 10 ; returns pack [20 10]
]
Coolio.