First, it is very difficult to manage a string without a reference
count. The current vala implementation is to assume that strings are
immutable, and to copy the strings almost everywhere where increasing
the ref-count should be used. The copying mechanism produces workable
code, but doesn't work in a efficient way. This is where it hurts.
I am not quite sure, to me you seem to mix up copy on write string and shared buffers, copy on write strings are just an optimization, and they don't need to be in GLib. Concerning shared buffers, string are *not* used in vala for shared buffers, simply because a string in vala is a utf-8 encoded *immutablle* byte sequences. a byte buffer is represented using uchar[]. Right now vala supports is pretty young concerning array supports, they are hard to manage in the first place because of the C quirks (null terminated arrays, vs arrays with an extra parameter to specify the length).
To keep it simple, why don't you just write a ByteBuffer class inheriting from GObject ?
Secondly, vala doesn't introduce any additional dependency other than
GLib, to implement it in VALA level, the only way is to embed it in the
compiler. A compiler with embeded code to do a ref-counted string
doesn't sound nice. This is why I think it should be done at GLib level.
