... until this thing actually gets traction and one decides to integrate a native TimL interpreter into vim alongside VimL (making this implementation a shim for older versions). Of course this would create two competing standards (until vim 8?) but the more than reasonable out of the box interop and readily available usefulness and unleashed power (you mentioned macros to alleviate pain points) makes it a honestly very reasonable scenario compared to python/ruby/lua bindings, which are honestly foreign and require an external dependency.
All of this is a sign of a brilliant hack: immediately useful despite having to bear with some caveats, with a clear path towards the future. Thank you sir.
I am curious how much optimization TimL has. I haven't had a chance to actually look at it beyond the README (and I don't know if I'd understand anything if I did). Does it leverage an existing Clojure compiler, complete with optimizations, and treat VimL as a target architecture? Or is it closer to an AST transformation with all optimizations being hand-written for TimL?
Of course, I am in a rather unique position of being able to bang out well optimized VimL in my sleep, so paradoxically that biases me against my own creation.