Antiform packs that contain nulls, e.g. the "heavy null" ~(~null~)~, are a cornerstone of how Ren-C handles the situation of a branch that returns null... to avoid having such branches run, and then pass control to an ELSE even though the branch was executed.
This is both beautiful and a thorny edge case. Some constructs want to treat a boxed null just the same as an unboxed one. Others don't. It can be a bit hairy.
So to reserve the functionality for just light nulls and branches... I discourage the creation of packs with nulls in them for the ordinary functioning of routines--if you can avoid it (you sometimes can't). The general rule of thumb is that your functions should not put nulls in packs, and if they ever return null it should be the only return--not in a pack. (Similar guidance discourages putting error antiforms in packs, but making it the overall result.)
Case Study: SPLIT-PATH
So the SPLIT-PATH function in Ren-C is a multi-return, giving you two parts: the file component, and the path component:
>> lift split-path %foo/bar.txt
== ~('%foo/ '%bar.txt)~
>> split-path %foo/bar.txt
== %foo/
It seemed that a lot of calls to it wanted the directory, so I made that the first return.
The problem arises when a component is missing:
>> lift split-path %bar.txt
== ~(~null~ '%bar.txt)~
So you have SPLIT-PATH giving back what feels like a NULL, but will trigger a THEN and not an ELSE.
