With splices confined to isotopic GROUP!s, it occurs to me that isotopic BLOCK! could be an angle to solving multi-returns.
The problem of not being able to return NULL or VOID would be solved by having the protocol speak in meta values:
>> ^ transcode/one {abc def}
== ~['abc '{ def}]~ ; isotope
>> ^ transcode/one {}
== ~null~ ; isotope
It would sacrifice the sensitivity to asking how many return values were requested... a feature I felt pretty attached to. But it would offer a solution to the piping problems that plague things like even simply putting a multi-return expression into a group.
It would mean that doing a ^META casually inline in expressions would be crazier, you'd tend to want to unpack things:
>> x: multi-return-func
== <result>
>> x: ^ multi-return-func
== ~['<result> ~null~ '*]~ ; wait a minute what is all this crap?
>> [^x]: multi-return-func
== '<result>
Because I just had the idea, I don't know all the ramifications. But it's clear this would solve the issues with APPLY and other piping scenarios.
Evaluator behavior would be that any slots not expecting a "pack" isotope would just become its first item UNMETA, but then a ^META slot can do other things.
This would mean it would be your choice to use the output variable proxying feature to get multi-return mechanics. It would be a convenience feature of FUNC for those who wanted it, in order to give better documentation on the interface and to make it clearer in the code what you were assigning.
It Wouldn't Prevent Enfix Detection...
And it wouldn't rule out people who wanted to do cleverness detecting things on the left. They could use mechanisms parallel to what exists today. But that would defeat putting function calls in groups, etc. Which may be the right tradeoff for some scenarios.