I've outlined the reasons why this is a bad idea.
But there's another possibility: What if # was the representation of the space character instead of the NUL (0) character?
It would be a lot more useful. Space has a particularly ugly representation (#" ").
Because the 0 codepoint can't appear in Ren-C strings (only binaries), it hasn't gotten a lot of use. Any routine that deals in codepoints can use regular NULL when dealing with situations where there's no codepoint.
# is a bit heftier than _ but I've perhaps been too harsh about it:
>> print unspaced ["Have I been" # # # "too harsh?"]
Have I been too harsh?
Admittedly, it doesn't look particularly "space-like". But is #" " an improvement?
# As Space Feels Pretty Obvious Right Now
I'll mention that one of the motivations for making # the NUL character was because it was used for a time as the "canon truthy value" (e.g. the value of an argless refinement when used, in juxtaposition to the ~null~ antiform). I wanted as few possible accidents by having that value accepted somewhere that didn't mean it, and the lame reason I made it NUL was just to stop a few cases...like appending to strings.
So it was intentionally useless. 
The ~okay~ antiform does a much better job at that useless-except-branch-triggering role.
So Now, What About BLANK! ?
If we let go of the dream that _ represents space--and I make peace with the idea that people can learn that # means space--then it frees up underscore's meaning.
I'll mention that I've noticed a lot of single characters can stand on their own now:
symbols: [
? ~ * + - = < > | : / . ; words
$ & ' ^ @ ; sigils (maybe % will be, also?)
# ; now a space...issue (token?)
~ ; quasi-blank (trash)
_ ; blank
]
Of course there's some you can't do this with (brackets, parentheses, braces). And comma acts weird enough sticking to what's on its left that you probably don't want to do this unless you're quoting it (',) where it won't have that behavior.
I'm really on the fence here, enough so to say that I'm starting to think this just has to be an error.
If it did work, I think it does have to be additive...because APPEND to a BLOCK! of a blank is additive. I don't think it can act like an empty string when appending to a string, but append a thing to a block...that makes no sense.
So if you can do this:
>> append "ab" first [+]
== "ab+"
Then I kind of think that blank's underscore-ness is what we defer to here:
>> append "ab" first [_]
== "ab_"
But I'm not convinced this is helping anyone.
HOWEVER, I do think it should be what it FORMs to.
>> form _
== "_"
(I have some Big Thought on the meaning of FORM, which I'll write up at some point here.)