Despite long delay, the Yeti 1.0 version is finally released. The main 
improvements are JDK14 support via newer ASM library and finished 
reference manual. Some bugs were also fixed.
https://mth.github.io/yeti/releases.html
http://dot.planet.ee/yeti/reference.html
The delay has mostly been due having to raise children, and wanting to 
have full language documented before the release (with too little free 
time).
During this time I've become quite disillusioned with JVM as a platform. 
While technically excellent, it is quite huge beast in many ways (memory 
usage, startup times etc).
In recent years it is also getting new VM level features, which would 
require additional effort to retain full interoperability - for example 
it is unlikely, that Yeti would support the new records in near time.
The environments where JVM is used are often very conservative in the 
choice of tools, to not say hostile to anything but Java itself.
The platform is open only superficially, as shown by Android debate.
The Android is also a walled garden by itself in practice.
I tried to find ways to port Yeti away from JVM, but it is written in Java 
and tied tightly to the platform in a way, that it would require either 
full rewrite, or effort similar to it. For example, one of the strengths 
of Yeti is how easy it is to call compiler and evaluate expressions from 
Yeti code - this relies on ability to link and run compiled code on the 
fly fast, which is greatly aided by running on virtual machine.
In the end I've decided that the effort to migrate is too much to be worth 
it, and running well on native platforms would require changes in the 
language design as well. Javascript and Lua execution models are similar 
enough that transpiling could work (it is even done in Yeti fork), but we 
have things like BuckleScript and ReasonML. There has also been progress 
among natively compiled languages - OCaml has removed some of its rough 
edges (and getting multicore support), and Nim is now quite nice on 
the more imperative side. I'm omitting Rust here, as it targets more 
low-level niche. A gap seems still be in not having a good statically 
typed scripting language, a task that Yeti could have excelled, had it 
not been tied to the Java platform. Maybe Gluon fills it?
The conclusion is, that I'm continuing to maintain Yeti as it is, mostly 
fixing bugs and maybe occasionally adding new features (especially 
extending the standard library). May I call it a stable language, like in 
Debian Stable? ;) It is a tool that usually works well at some tasks, and 
there are plenty of alternatives in most situations, where it doesn't.
I will also try to get it into Maven repositories, when I have some time 
tinker with this - this would certainly make it easier to sneak Yeti into 
bigger Java projects. ;)