I've written up some of the issues that have arisen in another thread.
But I wanted to mention something else that's emerged:
Antiform PARAMETER! Being Ornery/"unset" is A Headache
One thing is a good idea: that's the premise of having FRAME! cells with antiform parameters in them be the representation of an unfulfilled parameter (or "Hole").
This means a function's interface can be expressed without having a special hidden "bit" to say what's a parameter description vs. a specialized parameter value ("locals" historically were specializations to nothing, but now you can use any value that isn't a parameter antiform). The antiform parameter state becomes the "I'm an unfulfilled parameter" bit, which is already a sunk cost in the system for how to deal with it.
It does mean that if you want to actually take an antiform parameter as an argument, it has to be a ^META parameter...even though it's stable. But that's not such a problem.
What is a headache is having antiform parameters be just as hard to handle as nothings/tripwires.
When you look at what I mention in the other thread about how you can't really "re-skin" actions anyway (at least with trivial mechanics), I think this suggests that whatever the "MAKE FRAME!" operator is needs to go back to filling the unfulfilled arguments with antiform blank. Antiform parameters need to be friendly when reflecting specs.
The optimization/correctness issues simply need to be addressed some other way.