Lil is not intended as a flavor of xTalk; it is its own programming language. As I note in the language manual it is primarily influenced by Lua and Q. I feel that a small, expressive language is easier to learn than a large, verbose language with a great deal of case-specific syntactic sugar, and that a functional, expression-oriented structure is more flexible than a statement-oriented structure.
Decker has a number of intentional limitations which I feel produce interesting creative constraints, which give it a unique texture and flavor, and which in some cases aid in providing pixel-perfect cross-platform consistency. I have written rationale for some of these design decisions here.
Decker does support color images; it uses a configurable 16-color palette. This thread details how to import color images. There are a wide variety of ways a user might wish to adapt a particular image to a 16-color palette, so in the interest of simplicity I make no attempt at an exhaustive suite of knobs and buttons. Web-Decker embeds the entire editing environment into freestanding, self-executing documents, and every feature must be carefully weighed against its cost in the form of that runtime stub's size. For the same reason, Decker avoids reliance on external libraries wherever possible; even if a third-party C library might be helpful in some situation it would invariably need to be ported to and maintained as JS as well (or vice versa).
As you observe, it is currently possible to generate and play sound on the fly, so an enterprising user could indeed furnish something resembling HyperTalk's "music notation" as a Lil module. See also Millie's JankyTunes contraption and other musical experiments. A built-in sequenced music playback mechanism based on a subset of the Amiga Module format is planned for the future.
I do not wish to have any involvement with LLM-based technology.