What was good: very flexible and complete set of features to allow easy rapid prototyping. Tons of features that made a lot of game and research projects possible over the years!
it's tiny, compiles fast and offers a lot bang for the buck :)
fnpublish forcing us to document the public api, was also a great choice.
The rcmd system and layering worked very well, also splitting visual stuff (l3d subsystem) from rest. The overall structure of the architecture and internal modules worked somewhat fine.
What was bad: fnpublish became home of implementations, instead of just forwarding to C functions!
This is the biggest biggest problem of the engine, and made it hard to get a real complete C api, or automatic wrappers...
main loop not in user's hand (although a manual mode exists).
Related the two above, the fact that luxinia is not just a regular module that you can "require" into your lua app.
renderer originally designed for "texture combiners" fixed function stuff, retro fitting to modern rendering features / custom shaders didnt work so well.
It's okay for single use cases (post-process...) but not for a full blown shader material system. Would not use Cg runtime anymore, just for compilation and manage shaders manually.
renderer redundancy checks way to fine-grained, instead should have used immutable "rsSurface" objects to group important states.
"vid" grew out of control and got messy over time
wanted even more renderer low level access, "rcmd" system was great but sometimes not enough. Doing more with Lua would have meant better low level access system (see luxinia2's luxgfx)
should have used devil image lib ;) also should have never invested into more than a obj converter all the additional work for other formats didn't pay off. Today would use "assimp"
ui is single window, single event only. Cannot do "render-to-texture" UIs? that are on 3d objects.
Luxinia2: will be a framework, not a complete engine/toolkit. Simply as it makes more sense to assemble what you need, then building and maintaining a larger engine. Doing more ad-hoc in Lua instead of C and always thinking of how it fits into the engine
Actually the good overweights the bad by far, despite the tiny text ;)
In it's current state, the engine compiles and should survive a test-run, but version 1400 source code was different. The main changes were ripping out "standalone" code to make the backend libraries, which became basis for luxinia2. This means that the backend libs actually were run live inside luxinia1, but it also means that during refactoring some things might have broken.
This rip out modularization actually might continue over the future, to transfer more of luxinia1 into luxinia2.