So I sort of feel like it would be a bit of a waste if you couldn't use the slash notation in paths to run a non-antiform FRAME!
So let's say you wrote:
>> manipulators: reduce // [
[get $append get $insert get $change]
/predicate get $noquasi/reify ; doesn't have a single name, should it?
]
== [#[frame! ...] #[frame! ...] #[frame! ...]
We definitely want picking with a TUPLE! to be inert, that's a central point of the good new world:
>> manipulators.1
== #[frame! ...]
But should you use a PATH!, I feel like this should work... I think... 
>> manipulators/1:dup [a b c] [d e] 2
== [a b c [d e] [d e]]
It's a bit weird to see a number-headed chain used to run a function. But, y'know, that's consistent with history:
red>> manipulators: reduce [:append :insert :change]
== [make action! [...] make action! [...] make action! [...]]
red>> manipulators/1/dup [a b c] [d e] 2
== [a b c d e d e]
...and since they don't have the alternative of TUPLE!, they don't have a way to avoid "active accessors".
More Often Useful Case Would Be Just frame/
It's actually useful to store inert frames in data structures. UPARSE does it for the combinator map. It comes up.
But I think people will want to do things like:
>> frame: make frame! get $append
>> frame.series: [a b c]
>> frame.value: [d e]
>> frame/ ; using this form of application would COPY the FRAME! before running
== [a b c [d e]]
On the other hand, I believe that the correct meaning of /frame is that it should not run the inert frame.
GET of (non-blank-headed) PATH! Should Yield An Antiform
We could disable GET of a PATH! when it looks up to a plain frame and not an antiform...and say that paths can only be used with inert frames during EVAL. But I don't see the point of that (and it breaks the natural layering, where the code interpreting the path is the same for both GET and EVAL).
So I think you should be able to GET either one.
But regardless of whether the thing you got to with the PATH! was a plain FRAME! or an antiform FRAME!... if you GET it I think you should receive an antiform frame back.
As a reader, I don't want to have to puzzle over what the result is going to be. Seeing GET of a PATH! and knowing that's going to be an antiform frame is more useful than I can imagine preserving the distinction ever being. Not only are antiform frames what you usually desire, if you'd wanted an inert frame you could have used a TUPLE! to get it instead.
So this seems pretty well decided to me.
Don't Permit QUASI-FRAME! or QUOTED-FRAME! To Run
I've already written up my thoughts on avoiding making quasiforms too friendly. It does make things awkward at times. But I think that awkwardness is for the best.
The same applies to quoted frames. I don't think tolerance of these forms by the core leads to anything good. It ties into why I don't want ('a = first [''a]) to be true... once you start ignoring things like quote marks and treating it as equivalent, people will get sloppy with their input...which ties your hands later on if you want to give quote levels some dialected meaning (e.g. use them for tunneling values in meta form).