Since this is functionally the same as a system that rates things from 0 to 3 stars (or 1 to 4 stars, although I don't like 1-to-4 'cause it fools me into thinking there's a 50%), I think actual stars would be a less surprising interface. That would also be nicer to red-green colorblind users.

:}

I almost didn't care to mention it. After all, if people are going to compose/publish code in places where prose is expected, they'll get bitten one way or another. For instance, really strange characters might be displayed as question marks, or a random ":o" might turn into an emoticon. But I was amused to find a curved quote code mishap within a day, just by accident: http://www.flashcoder.net/blog/?p=100

  The quotes you use in the MediaControlEvent package result in a
  syntax error in Flash if I copy from browser to Flash.
  
  Rather than:
  “headControl”
  
  should be:
  “headControl”

It's a reference, as you can see, since the keys in the table change when you change them from outside the table. It's just that the keys are being compared by structure rather than by reference.

(tab key) => nil

This is pretty much a casualty of using hash tables. The point of a hash table is that it redundantly stores a hash of each of the keys, then compares further keys' hashes to those hashes before doing more in-depth comparisons. If you modify a key, then the hash table's precalculated hash for that key may be incorrect, so the shortcut doesn't work properly anymore.

The PLT Scheme docs specifically don't promise anything about this:

Caveat concerning mutable keys: If a key in an equal?-based hash table is mutated (e.g., a key string is modified with string-set!), then the hash table's behavior for insertion and lookup operations becomes unpredictable. (http://docs.plt-scheme.org/reference/hashtables.html)

What I had ended up voting for in the poll though was Clojure. I figure it's lenient about types, it's very reliably cross-platform ('cause of all the business interest in maintaining Java), it has better documentation than Erlang, it can still communicate with C and Erlang (as pretty much any language can, apparently), and beyond that, it has a language-level focus on communicating with other JVM code, which should give you good access to lots of other well-worked-on codebases. As far as I can tell, once you've got access to C and JVM libraries, Python libraries are the next gold mine, but I don't know how to access those libraries except through Python somehow (like through system calls or something), so it didn't affect my decision. (Incidentally, for many of the same reasons I recommend Clojure, I'm hooked on Groovy, but I did consciously try not to let my own criteria make a difference.)

  * great documentation & write ups.
  * feature rich well supported libraries (i.e. database connections, vector graphics libraries etc..)
  * macOSX and Linux support.
  * active community of users at all levels. 
  * low overhead (I like that arc is a dynamic language, has type inference, and lexical scope)

First there's some thing that I want to do.

Then I look for libraries or API's that will do that thing for me.

If there are several options, I look for one which seems to be the most practical and straightforward implementation.

These days when I go through this process I most often end up with a library or API written for Perl, Python, Ruby, or Java.

What I would suggest is learning enough of each of these languages so that you can make library calls. Which is pretty easy to do; you don't need to learn a lot to do that.

  (let old-cut cut
    (def cut (seq start (o end len.seq))
      (let length len.seq
        (if (< start 0)    (++ start length))
        (if (< end start)  (++ end length))
        (unless (<= 0 start end length)
          (err:+ "cut: The sign-adjusted indices were out of range or "
                 "backwards."))
        (old-cut seq start end))))
  
  ;? (include "arctap.arc")
  ;?
  ;? (test-iso "cut should work for negative start and 0 end"
  ;?   '(2 3 4)
  ;?   (cut '(1 2 3 4) -3 -0))
  ;?
  ;? (test-iso "cut should work for positive start and 0 end"
  ;?   '(2 3 4) 
  ;?   (cut '(1 2 3 4) 1 -0))
  ;?
  ;? (test-iso "cut should assume 0 start and 0 end are same position"
  ;?   '()
  ;?   (cut '(1 2 3 4) 0 -0))

Unfortunately, if I have code that does something like (cut '(1 2 3 4) ref!start-trim (- ref!end-trim)), then this approach fails too (because of that double-zero assumption). In that case, I suppose I'd just resort to writing another function as a workaround.

  (def cut-sides (seq front back)
    (cut seq front (- len.seq back)))

    (let old-cut cut
      (def cut (seq start (o end))
        (old-cut seq
                 (if (start < 0)
                   (+ (len seq) start)
                   start)
                 end)))

  - `(if (is ,var ',(car args))
  + `(if ((testify ,(car args)) ,var)

  (case compound-key
    ((a certain key))   ...
    ((some other key))  ...
                        ...)