Bear with me here, but...
What about stealing % from FILE! (and killing FILE!?)
Unlike the syntax of URL!, there is nothing universal about % being a character for representing files. It's a Rebolism. Filenames and paths are just strings and can look like anything.
Whenever I get in a mood to talk about "NewPath", I stress that Rebol should use PATH! as the structural form of files. You should be able to put GROUP!s in them that evaluate...you should put BLOCK!s in them that UNSPACED, you should be able to do a for-each on them and visit each segment without using some other path unstructuring tool.
"but paths execute", people would say. Well, then there came the idea that you could put a FILE! at the head, so %foo/baz/bar.txt would be a three-element path, the first element being a FILE!. And you'd somehow have a rule that if an inert item were at the head of a path it wouldn't run. (of course, now bringing in a difference in behavior of (%foo)/baz/bar.txt. How could you put a GROUP! at the head of a FILE!, showing a place you wanted evaluation, but not evaluating immediately?
These concerns seem to melt away if FILE! is replaced with quoted words and paths.
>> file: %bar.txt
>> type of file
== word!
>> file: %foo/baz/bar.txt
>> type of file
== path!
>> subdir: %baz
>> file: %foo/(subdir)/bar.txt
>> reduce file
== foo/baz/bar.txt
>> root: %foo
>> base: %bar
>> extension: %.txt
>> to-local-file %(root)/(subdir)/[base "." extension]
== "C:\Projects\foo\baz\bar.txt"
It solves mysteries like "should files show the % when they FORM". No, because there's no such thing as a FILE!. If you want that it's a file encoded in the value intrinsically, you can always do it the formal way, via a file:// URL.
It solves things like "how would you get a structured file with a GROUP! at the head". Again, you aren't having some kind of FILE-GROUP! at the head, you're escaping the ordinary path as a whole...it's effectively a more pleasant-looking LIT-PATH!, which evaluates into a PATH!.
It's a pretty decent escape character
It's a little bulky, but it's even-keeled. You feel like you haven't been taken out of what you're reading and into the twilight zone, the way ^ and \ might look.
if word = %isn't [...]
It's wider than backslash and so looks better when stuck up against an already vertical-ish delimiter.
Compare %[...], %(...), %| and \[...], \(...), \| in both proportional and fixed-width fonts.
append block %|
append block %[...]
append block %(...)
It would mean that % evaluates to NULL, so you could use it instead of the NULL function that returns a null. For better or worse, you could thus unset a variable very quickly--without a word lookup or function call--with:
foo: %
Multiple escapes look a bit busy, e.g. %%%foo. A forest of 9 little glyphs to do what \\\foo does with three strokes and ^^^foo does with three hats.
But I don't think there's going to be a ton of instances of multiple escaping...clearly Rebol has gotten by so far with just one on words. Being able to do it with other types doesn't suggest to me a sudden viral outbreak of huge amounts of escaping.
And I actually don't hate the weird little forest of glyphs. It's at least strongly distinct from // foo and other places that would be much more common.
In this world, you could also get a "filename" via path in code via LIT, if you didn't want to trip up the escaping in your shell with issues regarding %...
r3 --do "file: lit foo/baz/bar.txt | data :read file..."
Mechanical Concerns
It sounds pretty good, though the devil's in the details...but it looks worth pursuing.
The only obvious interaction with existing notations is that escaped percents would look like %10%. Which, well, actually that could be a useful notation in some dialect. Who knows. 
At least it's not \/.
One place you get in trouble is if your filenames contain words or patterns that are not legal escaping in Rebol, and you tried to use them as strings with the slashes inside of them. Previously you could say:
file: %"/c/Program Files/..."
And you'd be able to have it do some transformation or another to give it backslashes. But here you are using a completely fabricated path format in the first place. Why not:
file: %/c/"Program Files"/...
TEXT! and WORD! could be interchangeable. But really, this gets down to why you weren't just using a TEXT! and considering it a local file in the first place, and using a Windows formatted filename. If you could trust reading and writing to interpret it that way, and only do "backslash magic" on PATH!, it seems it would make more sense.
Another problem is how to deal with paths relative to root. Right now, /a/b/c has a refinement /a at the head of a 3 element path. That's a bit odd, and it feels like it might be better if it had a blank first element, and if you could have a blank last element.
Where you used to carry notation with you to indicate "fileness" with something like %1, if you just say file: %1 the evaluator will strip off the quoting level and file will be an INTEGER!. So it's another type that FILE-TO-LOCAL would have to tolerate, or require you to say %"1" to bring it into the textual domain.
So there's no shortage of questions that would have to be looked at. But it is rare in this that we come across something that's obvious how to work out all the details at first. You have to try and see, and see if when you start looking at it under a new light if solutions jump out or not.
That day when you delete the PATH! dispatch code for FILE!...
Speaking as someone who knows the code, FILE! was a catastrophe. Its mission and definition unclear, its implementation spotty.
Here is my suspicion: That Rebol has overplayed its hand in terms of what it can bring to the table with a FILE! literal datatype, and functions like READ should take URL!, TEXT!, and PORT!. If you have a more fluid way you like to work with your files in your source, you do so with the parts box of things like WORD! and PATH!, but before you get to the file I/O, you explicitly convert what you were working with into a TEXT! (or URL!) that says what you mean.
(I'll re-bring up how Carl used plain PATH!s and WORD!s, not FILE!s, in the R3-Alpha files list himself. That struck me as a rather crucial talking point when I saw it. And it made sense to me to want to do it that way--it looked worse with the percent signs AND you lost structural understanding. So I think the thing that doesn't make sense to me has kind of always been FILE!. It seems too hard to know when and how you'd want those parts converted automatically--and if you are given a solid parts box you shouldn't break too much of a sweat picking a point to textify things.)
So I'm strongly biased to seeing powerful new solutions that allow sweeping that code away. This feels like it might be up that alley... print [{...so we know why this doesn't print the percent} %foo]. Because it was removed from evaluation, and all PRINT saw was a WORD!.
If we look at real examples from a fresh point of view and ask "how can we make someone who's using the Rebol parts really happy" then having a unique string "flavor" that does nothing other than have a different type bit on it will possibly seem too weak to be worth it.
At least it's not