So I noticed an old thing that used to work had stopped working, and that was the use of vanishable functions through the ACTION! combinator:
>> parse ["a" "b" <c>] [collect [some keep text!] /elide tag!]
== \~()~\ ; antiform (pack!) "heavy void"
That used to give ["a" "b"].
It's not calling the ELIDE combinator, it's calling the ACTION! combinator and dispatching to the same old ELIDE function that you use in the evaluator... passing it <c> as an argument.
That ELIDE function is vanishable, but the ACTION! combinator is not.
One thing that might come to mind to do here is to say that the ACTION! combinator is vanishable, but that it does its own "heavy voiding" based on the vanishability of what it calls.
So if you call a vanishable function that produces VOID!, the vanishable ACTION! combinator would return that void as-is. But if you called a non-vanishable function that returned VOID!, the vanishable ACTION! combinator would distort that into a heavy void to avoid vanishing.
Sounds like it works... except then you can't use ^ to force vanishability on something non-vanishable that returned VOID!, because the ghost was lost by the time the BLOCK! combinator saw it.
This suggests that combinators need to know if they are being run in "vanishing mode" or not.
This is similar to the contextual knowledge of combinators knowing whether they are being negated.
So one simple way of doing this could be to say that those combinators which care to know can take a refinement and find out. When combinator frames are built, it would just be one of the fields that can be filled in (:UNAFRAID or somesuch)
The other possibility would be to say that you never get automatic vanishability from invisible functions and always have to use caret.
>> parse ["a" "b" <c>] [collect [some keep text!] ^ /elide tag!]
== ["a" "b"]
But Ren-C has come too far to make you throw in characters where they're not needed. 
I like the idea that a function that's invisible in the evaluator automatically would be invisible when called in PARSE too. So I think the idea of making the combinator vanishable, but able to coordinate and decide whether to do its own heavy-voiding is the right idea.