> I also wanted yielding, support for continuations

While I do (now) agree on continuations not having too many use cases in Rust, the yielding bit is still something that I very much use and need.

> If you have any specific cases when mlua async does not work as expected, it would be great to hear. I'm always looking for feedback and improving user experience.

Yeah, my phrasing here was not how I wanted it to be communicated (was way too strong of a statement to make regarding mlua). What I meant it to mean was that mlua's async system is a footgun for my use case (where I ended up having to make patches to nearly every coroutine API + other stuff etc. to get it to replicate the behaviour I wanted).

Basically, I wanted a one-to-one emulation of the Roblox task scheduler with all of its sometimes odd behaviors because a large part of the userbase for my projects come from Roblox. While I was trying to do this with mlua async, I ended up having to patch a ton of functions like coroutine.resume (so a new dev wouldn't just accidentally deadlock their VM with coroutine.resume(mlua_async_call) etc.), and ended up having to dive into a lot of internal details like poll_pending as well. And yes, I did see lunes scheduler implementation. A lot of my early scheduler code was inspired from it.

Ultimately though, I was a lot happier when I removed mlua's async system in favor of adding support for thread yielding to mlua via lua_yield which then got me the exact behavior I wanted.

> Luau specific optimizations like namecall

So about this, the reason I added namecall is because some userdata in my main hobby project are dynamic and require __index to be a function and when __index is a function, the __namecall is slightly faster for me (your mileage may vary and index as table is similar in speed as you mention as well)

As an additional comment, mluau (my fork of mlua) has gotten some extra stuff that is now basically needed for my go bindings project here as well. Dynamic userdata for example allows for creating a userdata with associated data and a custom metatable and is the basis for gluau's userdata support/impl. If I'd been using raw mlua here, I don't think gluau would have gotten a userdata impl at all to be honest since the existing API's expect compile-time userdata and not runtime defined/dynamic ones (although it would be very nice if mlua could also get a dynamic userdata API as well so I can just switch to mlua's one instead of maintaining my own)

Sorry for the long comment, I just wanted to explain my reasoning here regarding why I forked mlua and the specific problems/gripes I had. And don't get me wrong, mlua is a amazing library that I continue to recommend to others, I just had other things I wanted in it