With splices confined to antiform GROUP!s, it occurs to me that antiform BLOCK! could be an angle to solving multi-returns.
The problem of not being able to return things like NULL or VOID would be solved by having the protocol speak in lifted values (e.g. each element in the parameter block would be one level up, so quoted or quasi.)
>> lift transcode:next {abc def}
== ~['{ def} 'abc ]~
>> lift transcode:next {}
== ~null~
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 LIFT casually inline in expressions would be crazier, you'd tend to want to unpack things:
>> x: multi-return-func
== <result>
>> x: lift 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" antiform would just become its first item UNLIFT-ed, but then a ^META parameter can do other things.
It Wouldn't Prevent Infix 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.