The concurrency issue is not mine to fix. Javascript provides native concurrency by Web Worker which (compared to Erlang processes is a very heavy-weight, no-shared code environment. LuvvieScript is just realising that (given those prior contraints) an OTP-ish Erlang dom-script language can be created.
The alternative (a light-weight process language) involves building a scheduler in Javascript - which is a very different beast to a transpiler with a message-consuming/emitting runtime built with existing JS libraries.
To be brutally honest, the later is beyond my competancies.
Fortunately somebody has already made a implementation and you could try to use it as a base layer for your own system. I don't how easy it is to interface with Clojures core.async, but I guess its probably possible.
It might be a interesting exercise to implement Erlang Actors on top of this and then expose it to a JS interface. This might be a good idea in general and not just for your OTP-ish langauge.
Also I want to say that I came a across as very negative, I just wanted to say that LuvvieScript is quite cool and useful. WebWorkers are a much better primitive for Erlang style stuff because its shard nothing even on the server (I think). In really the browser should really provide a API for either shard memory threads or proper Erlang/Go Style threads.
The alternative (a light-weight process language) involves building a scheduler in Javascript - which is a very different beast to a transpiler with a message-consuming/emitting runtime built with existing JS libraries.
To be brutally honest, the later is beyond my competancies.