> The name is then a bit misleading. The established symbol-xxx
> procedures work on symbols.
>
> Consider changing its name to something like append-to-symbol. Or
> generic-append/symbol. Analogous would be append-to-vector,
> append-to-string, ...
Common Lisp has:
> (concatenate 'string "fo" '(#\o #\b) #(#\a #\r))
"foobar"
> (concatenate 'vector "fo" '(#\o #\b) #(#\a #\r))
#(#\f #\o #\o #\b #\a #\r)
> (concatenate 'list "fo" '(#\o #\b) #(#\a #\r))
(#\f #\o #\o #\b #\a #\r)
Encoding result types as symbols is not (as Marc says) very Schemey.
I posted "Symbols as strings" as the initial proposal because it's a
good example of something that's neither substantial not mature enough
to be a SRFI.
Now that we have a concrete example and an explanation, I'll offer this counterclaim: SRFIs don't have to be "substantial" in the sense of defining lots of symbols. Consider SRFIs 2, 8, and 243, each of which defines just one symbol. As for "mature", nothing starts out mature; everything has to go through a maturation process, and that process can happen on a SRFI email list as well as anywhere else.
I kind of regret that I have spent so much time writing complex SRFIs, which give the impression that if something is not complex it's not suitable to be a SRFI. I have also focused on R7RS-large "batteries" stuff and not written any SRFIs that are only for specialized use, though
https://github.com/johnwcowan/r7rs-work/blob/master/RoleBasedAccessControl.md is a pre-SRFI that was never intended for R7RS.