I tinkered with the code a bit to do this adjustment: that <opt> means the type-checking phase accepts NULL, but not VOID... and during callsite-oriented operations, both the <opt> parameters and argument-taking refinements will convert VOID to NULL.
In such a model, trying to build frames and set ^f.refine: () won't work, you use NULL. So in essence, the need to convert from VOID=>NULL is a responsibility of "frame builders" to decide if that's the "service level" they want to provide.
As I put it:
It's frustrating to have such a dichotomy. Because the whole point of "lift the universe" was to produce a single "currency" of FRAME!, so that phases didn't have to worry about it.
But this is saying "parameter convention" and "type checking" are intrinsically distinct. Which is obvious if you buy into the Rebol concept of "fexprs are good", because when you have a "quoted parameter" the only meaning of type checking is of the literal entity at the callsite, not the evaluation product.
Hence you always have a tension: are you the kind of thing that is concerned with "parameter fulfillment" or are you the kind of thing that does the "work once the parameters have been fulfilled".
Will Confess, I'm Saddened By The Tension 
My wish with "Lift the Universe" was that it would create a nice, universal currency for FRAME!, so one didn't worry about "some moment" where frames transitioned from unlifted to lifted representations or anything like that.
I guess that if I'd thought about it a bit more--I'd have realized that "parameter conventions" (e.g. permitting literal arguments at all) raises a question of that "moment". Does an ENCLOSE or an ADAPT or other compositional mechanic need to consider whether a parameter is literal? If not, then taking the "literalness" into account is another "moment".
I don't think this is an indictment of ^META-representations being able to store unstable antiforms. I think that tool has cut down on the number of places where these "moments" exist, and shouldn't be blamed for this problem.
It's just that while it cut those moments down... it didn't wipe them out completely... and drew attention to the ones the medium has accepted.
Allowing such a thing as a "parameter convention" is a weird design tool, meaning that there is such a thing as "parameter fulfillment"... distinct from type checking.
The problem becomes how to articulate the layering
I think realizing that the needs of an <opt> parameter and a refinement-with-args are similar, unifies them in parameter convention.
It's fuzzy right now but I think it's sifting out to say what it means to operate at the FRAME!-level vs. at the "parameter" level is shaping up, a little bit.
It's not like design dichotomies like this are inherently illegitimate (think Kernel mode and user mode, via a bit the CPU recognizes). Sometimes you draw a line. It just wasn't obvious that refinements and optional parameters used the same bit, but... that's making more sense now, so the question is how to make the code that does it make sense.