Possible to fix glaring Gjs API issues before GNOME 4?

[Nikita Churaev <lamefun x0r gmail com>]

OK, so it seems that GNOME has a serious aim on making GNOME/JavaScript
the preferred platform for new newbies. However, there are some API
issues that make Gjs confusing, and bad for PEOPLE.

1. Some functions return useless "success" boolean: for example
[success, contents, etag_out] = GFile.load_contents(). When C
g_file_load_contents returns false, it also sets GError, so in Gjs it's
either true or the function has thrown exception. The GObject
Introspection developers have already introduced "(skip)" mark for such
return values, but they won't add it to existing API to avoid backwards
incompatibility. What about adding "(skip2)" mark that only Gjs will use
and replace it to "(skip)" when GNOME 4 comes?

2. The contents of GFile.load_contents itself is a binary data and yet
is returned as a string, it should be returned as a Uint8Array.

3. Gtk.TextBuffer.set_text(text, length) --- length argument is useless,
since JavaScript uses UTF-16 and length expects length of UTF-8 string.

4. It's impossible to create custom Gtk.TreeIter from JS (no
constructor), so can't implement a completely custom Gtk.TreeModel.

6. Gjs adds a prefix "Gjs_" to names of all GObject classes made in Gjs:
"MyMainWindow" becomes "Gjs_MyMainWindow" and it's pretty confusing when
you try to style it with CSS.

Is it possible to fix these issues at least in Gjs ASAP without having
to wait for GNOME 4, as there are still very few Gjs applications, so we
don't have to worry as much about backwards compatibility as in eg.
Python.