adv3lite design decisions

I sort of get what you’re talking about there. I brought this up before, albeit slightly differently. See:

Those conversations, as you can see, often went nowhere productive. Keep in mind that is more likely due to my own lack of ability to articulate my points well enough.

In classes I’ve taught, where I’ve used TADS 3, there was no concern about the “complexity” of the Adv3 library, defeating much of the purpose of Adv3Lite for many people. In fact, Adv3Lite was more often than not seen as a complication not worth exploring.

However, this being said, there are, in my view, some demonstrably nice things that Adv3Lite introduces. But, as you’ve noted, the inconsistencies here and there make them a bit problematic to port directly to Adv3 in a lot of cases.

What I’ve found people often needed was simply a bit more of a refined map to Adv3, rather than a new library entirely. The good news, of course, is that nothing is stopping anyone from continuing to use Adv3 just as it is and, thus, never considering Adv3Lite at all. It is also possible, via some juggling of code bits, to retrofit some of the better aspects of Adv3Lite into Adv3.