Experiments have run the gamut to where a plain BLANK! once would opt out of appending to a series, and you had to quote it to append it:
experiment>> append [a b] _
= [a b]
experiment>> append [a b] quote _
== [a b _]
But the satisfying world we have now is that anything you can pick out of a block will append as-is to another block. So adding a blank is additive:
>> append [a b] _
== [a b _]
It feels like a decent fit to say that appending a blank to a string is additive...since VOID and such are available if you want to opt out:
>> append "ab" _
== "ab "
Though it raises the question of what BINARY! should do:
>> append #{0102} _
== ???
It seems that adding a UTF-8 representation is the story for ASCII:
>> as binary! "AB"
== #{4142}
>> append #{0102} "AB"
= #{01024142}
But when it comes to integers, strings append the molded form...while binaries just add one byte, not the bytes of the formed string of the integer:
>> append "ab" 10
== "ab10"
>> append #{0102} 10
== #{01020A}
A bit of a mixed bag, that could support arguments that BLANK! could be "the space of binaries" (e.g. #{00})
>> append #{0102} _
== #{010200}
But I think that's not so useful. It's more likely that the character representation of space is useful:
>> to binary! #" "
== #{20}
>> append #{0102} _
== #{010220}
Ren-C FIND and PARSE mechanics already allows you to search for strings in BINARY!, implicitly looking for the UTF-8 representation.
What If _ Was Really The Canon Representation of Space Chars?
>> pick "ab " 3
== _
>> #" "
== _
>> char? _
== ~true~ ; isotope
>> space? _
== ~true~ ; isotope
I've mentioned that single character intents are on the rise... we could call quoted void (apostrophe) "blank" and it could be used in contexts where you want to say there's no value:
>> blank? first [']
== ~true~ ; isotope
>> blank
== '
You'd still have _ as an evaluator-inert dialecting part that can't be redefined. You just would need to use something like # or ' or ~ in cases where you had a slot that could be either any character -or- some out of band thing.
Off the top of my head, I can see a few problems. If _ became a character literal, it shouldn't be used for vacant spots in paths. So let's say paths start using this "new blank":
>> as block! first [/a]
== [' a]
Doesn't look too bad, but if you want to parse it you need double apostrophes to match those spots:
parse [/a] [into path! ['' 'a]]
This is because a single apostrophe is matched as void, e.g. matches without advancing the parse position. And it wouldn't work if you used a word to reference the blank:
>> parse [/a] [into path! [blank 'a]]
** Error: To match a QUOTED! you must use @blank
>> parse [/a] [into path! [@blank 'a]] ; would need to do this...
== a
But it's not awful, and at least it doesn't silently treat the quote as a vanishing rule.
It's still kind of an interesting thought to make _ the literal char! of space. Still inert, still usable in dialects. It would leave ' and ~ as "friendly nothing" and "unfriendly nothing".
>> spread first ['] ; would return void
>> spread first [~]
** Error: Cannot spread meta-NONE
Either way, I think the conclusion here is that append #{0102} _ should be #{010220}
