Circa 2023 we now have a PACK! representation simply as isotopic blocks, with the "unpacking" done by the internal implementation of SET-BLOCK!
>> pack [1 + 2 10 + 20]
; first in pack of length 2
== 3
>> a: pack [1 + 2 10 + 20]
== 3
>> [b c]: pack [1 + 2 10 + 20]
== 3
>> b
== 3
>> c
== 30
It's much more freeform, and can be META'd and UNMETA'd into a quasiform...allowing you to put as much distance between the generation of the pack and the unpacking done by SET-WORD! or SET-BLOCK!
>> [b c]: (print "No tight coupling of PACK with SET-BLOCK!", pack [1 + 2 10 + 20])
== 3
>> c
== 30
>> meta pack [1 + 2 10 + 20]
== ~['3 '30]~
Hence the PACK! representation now underlies the entirety of multi-return mechanics. This allows wrapping and composability options for multi-return that were not possible with the early implementations.
Due to its generality you can do interesting things that don't involve making a multi-return function at all, such as having some branches of a CASE return packs while others don't: (The /B indicates optionality, and you're okay with no value in that slot to unpack.)
[a /b]: case [
conditionA [1]
conditionB [pack [2 3]]
conditionC [4]
]
Neat though all of this is, questions are raised about which constructs must--by necessity--decay packs to their first value. So there are still dragons to be slain here.